On 10/30/2012 02:34 PM, $B0u>l(B $BG50!(B wrote: > Right, and I am talking about relatively small amounts of data, not movies or > something. The reason I thought of SHM is that there would be no need to > decode the structure into a string and re-encode it, etc. Instead, the > application could somehow pass a message and a pointer. The receiving > application then takes over management of that record (or whatever), and the > sending application forgets about it (and allocates a new one next time it > needs to send something). This wouldn't work. You cannot pass a pointer to process A that references memory of process B. You would receive signal 11 (SIGSEGV). You could of course copy the block of memory (the object you're trying to transfer) into shared memory, which you then can access from both programs, but then I do not see the use of a message with a pointer (just start the object at offset 0 in the shared memory block).
Either way, this approach wouldn't be `safe`, as any pointer contained into the object/record/<whatever you call it> also needs te be re-allocated in the shared memory block. Thus strings and dynamic arrays would provide for quite a royal pain in the arse to `share` them. Encoding the object solves this problem. This does not mean that the data cannot be in binary form however (-> no need for IntToStr and vice versa!). All integers/floats can still be stored in identical the same way (i.e. 1/2/4/8 bytes fixed length), and need not be encoded/decoded in any way, they just need to be copied over from the buffer to the appropriate location. Strings can easlly be stored as an integer (the length field), followed by the data of the string itself; just as dynamic arrays. Thus if you have a class which contains a number and a string, you would encode it something like this (think as if you're saving to a file, but do not optimize for size): <type:fixed length (say, one byte?)><integer from class: 4 bytes for objfpc><length field of string: also 4 bytes, could also be 2 if the strings aren't longer than 65535 chars><data in the string> The type field is obviously needed for constructing the right class. Note that this type cannot be a `class of ....` type, as this is in essence also a pointer (to the VMT if I recall correctly). Then, as Jorge mentioned you only need to provide a neat little factory that `converts` these buffers to classes with which you can just continue in the usual OOP way. Hope this helps. -- Ewald Events don't necessarily happen in chronological order; yet somehow they do persist to happen. Sometime. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal