Re: [boost] [serialization] Regressions?

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
www.boost-consulting.com