
"Robert Ramey" <ramey@rrsd.com> writes:
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,
I never feel I have to use a const_cast to const-ify something. If the code I'm working with isn't broken, I almost never have to do anything, because a mutable object is-a const object in C++. But if I did have to do something, I'd let implicit conversion take care of it or use implicit_cast.
its likely that he plans to change the value during the course of the creation of the archive.
And you hold this belief based on... what? As far as I can tell, it's just a misunderstanding about the meaning of "const."
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.
Or you could take the simple way out and implement Peter Dimov's suggested semantics. -- Dave Abrahams Boost Consulting www.boost-consulting.com