David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
So my motivation was and is purely practical. I expected that the only people inconvenienced by this are those that are inconvenienced by const in general. And that they would handle it the same way. They would just grumble and apply a const_cast and forget about it. I'm certainly not prohibiting that.
Robert,
How is your rule any different from trapping serialization of all non-pointer types whose name begins with an uppercase letter? There's an easy workaround (just serialize via pointer) and
the conditions of the trap have as much to do with the problem you're trying to detect.
Of course this is what I'm not seeing. I believe that if someone has situation where he feels that he has to use a const_cast, its likely that he plans to change the value during the course of the creation of the archive. If its not marked "track_never" he will set himself up for lots of pain he doesn't need. I concede this is speculative on my part. But the examples presented so far have reinforced my beliefs on this. I greped the serialization library and code and cound 40 BOOST_STATIC_ASSERT s. I don't know how many are cases similar to this one but at least some of them are. In a number of cases there is BOOST_STATIC_WARNING commented out. So looking back, I've wrestled with this on a regular basis. One way address the concerns who don't want this "help" from the library writer would be to introdue the concept of a warning level - ignore, warn, error to be used in the places where these macros are. Unfortunately, this entails a whole new concept to be implemented, tested, and documented and I don't see how I would have time for this. I'm tying up a couple of loose ends regarding shared_ptr serialization and then there is the compiler/tool issues which generate a large number failures. Robert Ramey