Quote:

ja, that's the method I use.
anyways, reading and writing blocks of data on stream is same as writing the whole file.
the data goes in, one by one, in BYTES.
thus, there is no other vartype basically available than ints ([for kixtart, LONG] with the current requested method)
but, as variant supports other types too, it can take string input (in form of character array)

anyways, the data is always to be byte ordered and if not huge overheat wanted, the array way is the only way to do it efficiently.



Not quite right. File IO is cached and buffered, and written efficiently. You *can* make it inefficient by flushing the io stream after every write, or setting the file io to unbuffered.

There is a small overhead in system calls, but it will be far less that the overhead required to use KiXtart to convert data between types and manage arrays.

Data in files is as you say unstructured. You have to impose a structure on it. You could do this by reading in the bytes and then write KiXtart UDFs to convert it. Bytes, ints, uints and strings are a doddle to convert, anything with a mantissa is a bugger though. Much easier to read the bytes directly into the correct variable type, which "automatically" coverts the data.

I'm not trying to teach you to suck eggs here, but I don't know how familiar you are with file io so apologies in advance if you already know this stuff.

As a quick example, to write a single integer "i" to an open file "fpFile":
Code:
fwrite(&i,sizeof i,1,fpFile);

To read it back again:
Code:
fread(&i,sizeof i,1,fpFile);


There is no conversion done - the contents of the variable are simply read and written.

You need the additional data types when reading and writing as the file you are accessing may be used by other applications. If you limit the types of data that may be written you also limit the files that you can access.

There is no reason not to accept variant data and cast/convert to the correct type, using scanf/printf for example.