Re: [AD] load_datafile_object using index

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2005-04-18 at 22:05 +0200, Evert Glebbeek wrote:

> Hehe... so do I. Perhaps if we unanimously agree that it should and can be 
> included...? Probably a bad idea, but still...

Probably... maybe we should find someone else and let them decide? :)

> Anyway, my main point of criticism at the moment is the API itself. I would 
> prefer either (apart from load_datafile_indexed->load_datafile_index)
> 
> int *load_datafile_index(const char *fname, int *indexc, int **indexv)
> 
> where the routine itself allocates the array and returns the pointer in 
> indexv as well as through the return value and the size in indexc, or
> 
> int load_datafile_index(const char *fname, int indexc, int *indexv)
> 
> where the user specifies the size of the array and the routine fails with 
> an errorcode if it is not large enough. The proposed fixed-size array that 
> has to be large enough is too inflexible and insecure. We probably should 
> also have a version that takes a DATAFILE object as argument instead of a 
> filename.
> 

I agree, the user-provided big-enough array is bad. Another idea would
be:

/* returns NULL on failure */
DATAFILE_INDEX *generate_datafile_index(const char *name);

/* pass the index generated above */
load_datafile_object_indexed(const char *name, DATAFILE_INDEX *index, int item)

/* frees the index again */
destroy_datafile_index(index);

I.e., make this all transparent to the user.. since there will never be
any need to manually read out the file offsets - so just hide it inside
a DATAFILE_INDEX object. DATAFILE_INDEX would just be typedefed to long*
for now, but later it could be a struct which also contains a hashtable
of the NAME properties, and then we could have:

load_datafile_object_named(const char *dfilename, DATAFILE_INDEX *index,
char const *name)

Without needing to change the API.

-- 
Elias Pschernig