noter:
if ( (_head.dataStart - HEAD_SIZE - (FPOINTER_SIZE * _head.filledRecords)) < FPOINTER_SIZE ) {
_AumentaEspacioIndex();
}
Ya veo... basta con que la distancia entre último índice de la tabla y primer registro sea menor a FPOINTER_SIZE (supongo que son 4 bytes); también funciona.
Aunque si se hubiera querido, se podría llegar a lo mismo pero con menos cálculos matemáticos; sin embargo no estoy seguro si optimizar eso nos daría un rendimiento significativamente mejorado.
Eventualmente llegamos al punto en donde el rendimiento recae solamente en la RAM; para reducir su consumo, ciertos datos se tendrían que consultar con cálculos matemáticos que posiblemente se tengan que repetir múltiples veces (menor rendimiento). O podríamos hacer que dichos cálculos solo se ejecuten una vez (mayor rendimiento), pero eso implica consumir más RAM.
Al querer optimizar ambas cosas, ahí es donde quedamos "entre la espada y la pared"
noter:
Evidentemente, para un tamaño pequeño de registro, este proceso se va a repetir con más frecuencia al agregar registros.
Entonces habrá que buscar el balance entre el tiempo que se tarda el proceso vs la reducción de la probablidad que se vuelva a ejecutar.
noter:
Incluso ahora me doy cuenta de que si el tamaño registro es menor a cuatro bytes (lo que sería un mal uso de la librería por otra parte) se corromperían los datos al no abrirse suficiente espacio para un índice con una sola operación _AumentaEspacioIndex. La solución sería cambiar if por while, aunque como digo, usar la librería en esa situación sería un contrasentido.
O haces eso, o agregas a la cabecera, el dato del tamaño "lógico" del registro; para forzar los registros a ocupar al menos 4 bytes.
Aunque, según la respuesta anterior, ejecutar un proceso complejo para obtener apenas un índice de espacio, también sería contraproducente.
noter:
En cuanto a localizar el índice correspondiente al registro que vamos a mover, hay que hacer una búsqueda de dicho índice.
Toma en cuenta que hay que buscar incluso en los índices de punteros inválidos; ya que dices que para insertar un registro nuevo, el puntero inválido aún debe apuntar al espacio libre.
Creo que ya me quedó claro: no me molestaré en crear algo que ya existe; lo que noter ha hecho no solo cumple, sino que ha superado mis expectativas de lo que tenía en mente (pero en cierto momento se me había venido una idea similar a la de la tabla de índices en vez de la lista enlazada, solo que él ya la había concretado).
Por supuesto que tiene sus desventajas, que (según la teoría) podrían echarte para atrás; pero su aplicación en un entorno más realista, muy posiblemente no sea gran cosa (y sobre todo si se admiten y reconocen las limitaciones de la implementación).
Donde esta implementación brilla más, es en la operación de búsqueda: si todos los elementos (registros) están posicionados según la definición del ordenamiento, se puede aplicar el algoritmo de la búsqueda binaria; la cuál presenta un buen rendimiento incluso en listas/conjuntos relativamente grandes.
PD: ahora que lo pienso, si en la operación de sobreescribir un registro no puedes permitir que hayan dos "iguales" (por definición), ¿será que en la operación de inserción tampoco?