"Robert Ramey" <ramey@rrsd.com> writes:
David Abrahams wrote:
Vladimir Prus <ghost@cs.msu.su> writes:
I know I'm coming in late here,
Yes you are. the original post was sometime ago and many of the issue on this subject were discussed.
I'm sure. I tried to go backward in time, but got lost.
but I have always expected that the library worked this way (actually keeping a map of saved object address to archive identifier is a usual arrangement). If it doesn't do that, I'm very surprised. How else do you do tracking?
Of course it works that way. It turns out the the library is sufficiently smart to skip tracking (and skip instantiating the code for tracking the indicated type) for types which are never serialized through pointers. The mechanism for implementing this is somewhat unusual
I'm pretty sure I do something similar in Boost.Python, so I can imagine it. If what you're doing is legal, it has to involve setting up a function pointer that can be called at runtime to do the tracking... or else my years of banging my head against similar problems were in vain...
and it seems may have caused a mis-apprehension as to what is going on here.
...but the means for doing it is completely independent from the question of whether the behavior is a good idea. :)
Also, if tracking a stack object is being made illegal unless it's const, I find that highly surprising, and I see no relationship between its constness and safety due to lifetime issues in this case.
Tracking a stack object makes no sense.
Au contraire; it does. It's easy enough to set up a little graph of objects on the stack. I'd like to be able to load that back in and ("obviously") get dynamically allocated objects. Why is that nonsense? I know a computational physicist who wants to serialize very large matrices, which are invariably going to be objects on the stack. Why is that nonsense?
doing so will result in an archive that cannot be loaded.
I don't know why that should be true.
Tracking an object whose value can change during the lifetime of an archive will also fail when the archive is loaded.
I don't know why that should be true. I can imagine wanting to keep a "was_serialized" mark on some object. There is often data in an object that's part of its real logical state w.r.t. the program (and thus shouldn't be marked mutable), but that shouldn't be serialized. Why does it matter if that data changes? I don't understand why the object's value -- other than its internal pointers and references -- is important to the success of loading an archive.
by requiring the << operator to take a const argument when the object is of a type that is being tracked, violations of the above rules can often be detected at compile time - thereby saving the programmer days of work looking for a mistake that will only be detected after a failed attempt to load a corrupted archive. (BTW, I'm the one that get's the email when this occurs)
Understood. Now you're getting email about the consequences of trying to prevent it. You can't win ;-)
Its concievable that there mght be a legitimate case where one wants to track an object that is not const during the course of serialization
I'm pretty sure you mean "is not constant." The problem here, or at least one big problem, is that non-const does not imply non-constant.
- but no one has presented a credible use case so far.
On the other hand, credible use cases for serializing non-const objects are common.
There are cases where the STATIC_ASSERT trips when its not stricly necessary but in all of my cases I found it easy to slightly restructure the code to avoid the problem. See Joaquin's previous post on this subject.
Still looking for the pointer to it.
In he rare case where one needs to do ar << t where t is not a const and it is inconvenient to alter the code to make it so, one has two options: Use a const_cast or use the & operator instead of the << operator. Is this such a price to pay to get traps in usage of the library that is very likely an error? Is fair that the rest of have to forego this facility just so one programmer doesn't have to write ar & t instead of ar << t ?
You mean ar & my_non_const_object works? If so, I'm less worried. However, the non-uniformity seems a bit gratuitous, and I think you're setting a bad precedent by equating non-const with "will change," even if that interpretation is overridable.
I could easily build a small self-referential structure on the stack that I'd like to send to a archive, and non-constness would be essential in such a scenario. Of course I could create const references to each object and serialize those but why make me jump through hoops?
That's not the case here. you might build it on the stack but it would have a type.
? Everything has a type.
Normally that type would be serialized by something like save(Archve &ar, const T & t). From then on T is a const and there is no problem and no trap.
No, the problem is that there are other nodes in the structure that t refers to via non-const reference or pointer.
The problem comes when you do somethign like
for(... X x = ....() ar << x
where X is type that maybe tracked. I'm sure you can see the problem here if you're trying to track either to recover pointers or eliminate duplication.
Yes, I see the problem. But for(... X const x = ....() ar << x is no less problematic from that point of view.
I'm starting to care.
The whole thing has been blown waaay out of proportion.
Maybe. These days, I am putting a lot more attention on small details of libraries that I hadn't seen much of before. It isn't personal; I am just trying to keep the overall quality high.
One little observation. It has come to my attention that const is avoided by some programmers due to its tendency to ripple its effect throughout the code. Personally I think this is a great mistake and the extrat pain in the neck caused by this ripple effect is more than compensated by the detection of bugs resulting from side effects.
I agree, but AFAICT you're giving const (or lack thereof) a meaning for which there is no precedent in C++. -- Dave Abrahams Boost Consulting www.boost-consulting.com