Mindboards

m-goldberg wrote:I hope John Hansen will comment on this. John, should Read be able to read in an array of ints with a single call?

No, that's what ReadBytes() is for.

Thank you muntoo!
Now it all works!
I have been trying to figure it out for so long and now it works!!

muntoo wrote:

m-goldberg wrote:I hope John Hansen will comment on this. John, should Read be able to read in an array of ints with a single call?

No, that's what ReadBytes() is for.

ReadBytes would let you read in an array of bytes in single call but definitely not an array of ints or longs. The problem with reading in an array of anything is knowing how many bytes to read. The ReadBytes function requires that you provide that information. For structures and simple types like long, int, float, etc... the compiler knows how many bytes that type needs to have read from the file in order to unflatten the bytes into the variable provided. This operation is a firmware VM opcode which works if you give the opcode the right type as the pattern to use when converting the array of bytes containing the data read from the file into the output variable. You can flatten an array containing any type into a byte array (actually a string since it has a null added at the end) since the variable you are flattening has all the information the firmware needs such as the element type and the number of elements in the array. But when trying to read that data in from a file to which it was previously written the compiler has no idea how many elements were previously written to the file so the API function can't automatically figure that out like it can for a Read of a int or a float or a user-defined type. If a Write operation of an array included a 4 byte header (by convention) containing the number of bytes being written then a Read of an array could use that to figure out the mystery and solve it.

Do you guys think that would be a sensible change to make to the API functions? I'm not sure if that is entirely feasible given the way these functions are written but if I get enough feedback suggesting this is a worthwhile possibility then I can investigate it a bit.

John Hansen

John, how about a ReadArray API call? It could take the form:

unsigned int ReadArray (byte handle, variant & array, unsigned len)

where len is the number of elements to read into array. It would be up to the programmer to set len to correct value and you wouldn't have change the way arrays are written out to files. The compiler would know the size of each element from the declaration of array.

This has turned into a really interesting conversation, because we're ultimately discussing how to serialize data structures (which anyone who has programmed Java, RPC or CORBA is familiar with). In some programming languages it is possible for data types to serialize themselves (e.g. Java) if they conform to a certain interface. Native data types are serialized implicitly by the runtime, but structured types declare a serialization method that will "walk" the data structure and output it into a byte stream in a sensible fashion.

NXC currently has the ArrayOp function to support the various array operations (e.g. ArraySort, ArrayMax, ArrayMean). I'm just speculating, but would it be possible to allow an arbitrary function to be called for each element in an array through this ArrayOp() facility? If so then we could add an ArraySerialise operation to the mix.

Extending this line of thought; is it possible for ArrayOp to effectively become an iterator and allow a structured way to apply a function to each element in an array? (I suspect not as it would require functions as first-class language objects which the NXT firmware can't support).

Regards,
Mark