From: David Abrahams (dave_at_[hidden])
Date: 2005-06-28 10:17:34
"Robert Ramey" <ramey_at_[hidden]> writes:
> David Abrahams wrote:
>> "Robert Ramey" <ramey_at_[hidden]> 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.
>> 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
> 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
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk