----- Mensaje original -----
De: Robert Ramey
JOAQUIN LOPEZ MU?Z wrote: [...]
Wouldn't it be an option that pointers to primitive types will be handled as non-tracked? What would be the overhead of that option? In case this is an option, please consider my vote for inclusion as a new feature in Boost 1.35.
OK - that would work fine - but I also believe it would trip the infamous "const trap" so that might have to be considered.
Umm... Well, at first blush, seems like serializating a pointer to a primitive type is no different than serializing a pointer to a non-primitive type --the same const issues, controversial as they might be, are already present. Besides, this new feature would be a pure extension, in the sense that code that didn't compile before would do now, so, you're positively not breaking anything. [...]
So - although the problem never comes up for me I concede your point. I have erroneously confused the identity of two concepts - serialization and tracking. From that standpoint I'm inclined to make the change you suggest. The only concern is that it would breakone of the user traps that inhibits certain user behavior because it will almost surely lead to intractible problems.
Again, I don't see how ensuring that the const rule works also for primitive types is any harder than the current implementation, which only applies to non-primitive type --seems like all you've got to do is to extend the enforcement in a straightforward manner. But then again, you're the implementor and surely can see internal difficulties I'm not aware of.
Dealing with the trap is a pain - but its much less painful than dealing with user's who have done something that is permitted and seems natural to do end up having archives that cannot be read or recovered. I believe that serializing someting like std::set
will eventually lead to such problems eventually in most cases. To summarize, you're correct. But I'm concerned that just "fixing" the code will create new set of problems.
Thanks for addressing my concern! Well, if you're doing the change for Boost 1.35 we'll surely have plenty of time to detect any potential problems that might arise.
Robert Ramey
Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo