Boost logo

Boost :

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.
>> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at