In-Reply-To: <c7etkk$e3d$1@sea.gmane.org> lirong@hotpop.com (Li Lirong) wrote (abridged):

...

This well mean that all serialized longs have to be tracked.

I think the lib should only track it when it is serialized through pointer. And most of the time, primitives are not serialized through pointers. So there should be any overhead.

It's easy to construct cases where that goes wrong. Like: struct S { int x; int *px; S() : x(0), px(&x) {} }; And such cases aren't that unlikely in real code, either. For example, x might be a default, with px being settable to some other location. It's true that such cases are rare... however, that just makes it all the more important that when they happen, they either work correctly or are diagnosed as errors, preferably at compile time. Disallowing serialisation of int pointers altogether may be restrictive, but it gives a safe compile-time check. I suppose it might be OK to have an option where ints are tracked only when serialised through pointers, provided there was also an option which detected any mistakes at run-time. In other words, did the tracking for all ints but without outputting it. The two options would let you trade performance for safety, eg switched with #ifdef _NDEBUG. However, this seems like a lot of development work. In practice I expect serialisation of int pointers is pretty rare. If we have them, then sooner or later we may get cases like S, and then we have to move to some other solution anyway. Handling the special case in the middle doesn't seem worth it to me. Especially if error detection only happens at run-time, and perhaps only in debug builds. I'd rather tell the library exactly which ints can be serialised via pointers and which not, and the current solution seems a reasonable way of doing that. At least, I can't think of a better one. -- Dave Harris, Nottingham, UK