Christopher Li wrote:
I would rather not have that 4 byte prepended to every structure. Serialize is just one short stage of the life cycle of those c structures. Having the permanent extra space for just that is unnecessary. That 4 bytes meta data also limits what C structure you can work on. All you need is being able to map a point into some serialize object to keep track which object is tracked and which one is not. After you serialized the data. The meta data can be drop completely. So the price to pay is for every unknown object pointer, you need to do a dictionary look up. Only during the dumping stage. But that price is actually very small, when you dumping objects. You are mostly limit by the disk any way. The plus side is: you can work with any objects. You don't need to waste extra memory for serialization when you are not doing serialization. You can leave the object allocation code unchanged.
I concur and just wanted to point out that this technique has been used in the garbage collector for functional languages for the same reason: the type information is very small and almost completely static; no need to replicate it all over the data. It does make marshaling (this is the common terminology for what Alex calls "serialization") slightly more complicated.
Tommy -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
