Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-25 07:23:37

"Peter Dimov" <pdimov_at_[hidden]> writes:

> Robert Ramey wrote:
>> David Abrahams wrote:
>>> "Jeff Garland" <jeff_at_[hidden]> writes:
> [...]
>>> The hashing idea is a lot closer to the mark.
>> Not in my view
> I find that very odd, since you later go on to say that this statement:
>>>> NOTE: due to a change in the serialization library interface, it is
>>>> now required that all streamable objects be const prior to writing
>>>> to the archive.
> in inaccurate (which it isn't)

Actually, _I_ said it was inaccurate. You can stream a non-const
object just as long as you do it through a const pointer or reference.

How weird is that? What other operations do we have in C++ that work
on const lvalues and *not* on non-const ones? This is utterly
unprecedented and it subverts the fundamental C++ relationship that a
non-const object is-a const object.

> and explain that:
>> What is true is that the state of an object should not be changed
>> durring the process of serialization. That is the statement made
>> by save(Archive &ar, const T & t).
> The hash check does exactly that, verify that the state of the
> object hasn't changed.

Exactly, and the const check does not check for that at all.

If you extend the logic used to support the const check, a std::list
would have to be const in order to call .sort() on it. That's right:
it's an error for the comparison operator used to change any of the
list's elements in a way that would affect the sort, just like it's an
error for any serialization operator to change the objects being
serialized in a way that would affect serialization. Can you imagine
a sort() member function being const?

> Anyway; have you considered making the default tracking level to
> only track pointer saves but not value saves? This would instantly
> marginalize the problem.

Yeah, that was another option I was going to mention, but I didn't
want to further confuse things.

> Mixing object saves and pointer saves is fairly unreliable since
> it's order dependent (and will create problems later on if the
> object is versioned), but if one wants to use the library in such a
> way, the option to enable full tracking would still be there (and
> get the full const treatment).

Dave Abrahams
Boost Consulting

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