noter:
Ten en cuenta que esto sería interesante si quieres realizar algún tipo de estándar para poder leerlo desde un ordenador o de forma genérica desde otro arduino.
Para algo así serviría, de hecho.
noter:
Puedes utilizar la misma para poner unos datos de índice, ejecutar búsqueda sobre ella y recuperar los datos del registro. Vamos; que es bastante "reciclable".
El problema estaba en que la estructura sí entrara en el código principal, pero no en el atributo del objeto. Mira que al final es reservar espacio, en memoria RAM, para al menos dos estructuras iguales (sólo la operación de obtener un registro por índice no requiere del espacio temporal).
noter:
Sin embargo, ahora tras recuperarlo modificamos, por ejemplo su nombre: Zutano-Mengano-12345. Esto afecta al índice y potencial posición en la ordenación. Entonces, calcula la nueva posición, modifica el registro y mueve el índice a su posión pero, ¿Y si ya existía previamente un Zutano-Mengano-12345? En ese caso no toco nada y retorno error.
Entonces el método de la modificación se basa en: búsqueda (aquí es donde lanzas el error si una coincidencia existe), sobrescritura, y la etapa de ordenamiento de la inserción (salvo que el desplazamiento llega hasta la posición antigua del registro, y su dirección depende de si el nuevo es mayor o menor que el antiguo).
También he notado que lo tuyo no es una lista, sino un conjunto.
Matemáticamente, un "conjunto" se define como una colección de objetos llamados "elementos"; dónde estos no pueden repetirse (o sólo se considera una vez). La repetición consiste en tener al menos dos elementos iguales; la definición de igualdad depende de los elementos en sí. Lo que no recuerdo, es si, en los conjuntos, el "orden natural" de los elementos es relevante o no.
noter:
Por ejemplo un desplazamiento de 100000 registros arriba o abajo requeriría desplazar cuatro veces (unsigned long) dicha información.
Sería interesante poner a prueba esa limitante pero en un entorno más realista.
¿Recuerdas cuando discutíamos sobre el funcionamiento de la librería SD? Según mis cálculos, cada 127 desplazamientos (o 128 índices si se está creando un archivo nuevo) se tiene que actualizar un bloque/sector; tan rápido como SRAM jamás, pero tampoco va a ser estrepitosamente lento.
noter:
Lo que no hace es decrecer a demanda.
Y además la librería no lo soporta, no sin antes realizar el truncado a 0 bytes; aunque técnicamente es posible encoger un archivo existente, sin truncar totalmente ni crear otro.
noter:
Implementé el sistema de mover el primer registro de datos al final cuando necesito más espacio para los índices
Por eso hablaba de un puntero a la tabla de índices; con esa característica ya no se puede asumir que siempre va a estar ubicada contiguo a la cabecera.
Si el tamaño de los registros estuviera "alineado" a la tabla de índices siendo múltiplo de 4 (a nivel estructural del archivo, a nivel lógico sigue siendo el especificado), se podría aprovechar fácilmente el espacio que ocupaba(n) la(s) antigua(s) tabla(s) de índices. ¿No lo habías pensado así verdad?.
Esa es una de las razones por la cuál la tabla de metadatos en NTFS, y los subdirectorios de la raíz en FAT, son archivos; porque cuando son eliminados, reducidos en tamaño o desplazados, ese sobrante se puede aprovechar.
noter:
pero no implementé el método opuesto
Ni te molestes en hacerlo. Para el manejador de volúmenes FAT, hacer crecer un archivo es un trabajo laborioso; por lo tanto, es más eficiente reutilizar espacio asignado que volverlo a asignar. Lo mismo se puede decir de la tabla de índices: cuando urge no queda de otra; pero en la medida de lo posible, evitar reubicar y hacer crecer toda la tabla (ya me imagino el dolor de cabeza que representa ese proceso).
noter:
No es necesario en mi caso, porque la posición de la tabla de índices es fija y conocida, a continuación del header.
Pero si la necesitas expandir... ¿no la mueves del todo? Si me dices que la nueva ubicación es la "segunda parte", estás cometiendo fragmentación; y por ende, forzado a recurrir a la lista enlazada.
noter:
Si quisieras implementar un descriptor de campos sí tendrías que almacenar de alguna manera el inicio de dicha tabla.
Si la longitud del registro está fijada, ¿porqué debería preocuparme por que la composición cambie?
Si asumo que la composición no cambia porque la longitud tampoco, entonces los descriptores perfectamente pueden formar una sección de la cabecera.
noter:
Los registros pueden tener el tamaño que quieras, siempre que sea fijo. Los índices sí tienen tamaño de cuatro bytes.
Eso sí lo sabía. El detalle está cuando se quiere mezclar una cosa con la otra: los espacios (bloques) deben "alinearse" para un acceso siempre homogéneo.
noter:
Los índices están consecutivos y ordenados (y a continuación los borrados) y no permito fragmentación.
Si no permites fragmentación, entonces explica con más detalle qué le ocurre a la tabla de índices cuando tiene que expandirse.