On Fri, 24 Jun 2005 09:19:05 -0400, David Abrahams wrote
"Robert Ramey" <ramey@rrsd.com> writes:
David Abrahams wrote:
Vladimir Prus <ghost@cs.msu.su> writes: 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?
It's a valid use case -- the need for stack-based serializaton happens all the time with value-based objects. There are all sorts of places in a program where objects are constructed on the stack, initialized, changed, and then perhaps serialized. I might even serialize the same object more than once with modified contents. They can't be const because they are changed or assigned after construction. I really don't want a different syntax to remember. operator<< invokes a good analogy in my brain to remember -- '&' doesn't.
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'm worried people will get in the 'habit' of casting to use serialization. And in the real world that won't be using fancy C++ casts -- they'll get out the big bad c-cast hammer. And IME once the casting starts it has a way of growing -- programmers see the casts and 'learn from them'.
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.
I never stopped caring, I just got tired. Since the moment this change went into the library and blew up date-time tests and some of my other programs that were working perfectly I was unhappy. But neither Vladimir or myself have been able to convince Robert that this change is ill advised -- so I just stopped and modified my stuff. I ended up adding something to the date-time docs so that we can demonstrate stack-based serialization: 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. The following template function will allow for this (and is used in the date_time tests). At this time no special steps are necessary to read from an archive. template<class archive_type, class temporal_type> void save_to(archive_type& ar, const temporal_type& tt) { ar << tt; } Feels/looks like an ugly workaround to me... mr-blow-it-all-out-of-proportion-yours ;-) Jeff