David Abrahams wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Fri, 24 Jun 2005 09:19:05 -0400, David Abrahams wrote
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.
The non-uniformity is really a feature of the & operator itself. Its used for both loading and saving. The operations are not quite as symetric as they appear at first glance.
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'.
Yeah, with all due respect to the author -- who has designed a library that's by all accounts very satisfying -- this design choice is just all wrong. It doesn't detect what it purports to, and gives plenty of false positives. Because it's a compile-time check people will get used to doing what is required to subvert it.
This is very speculative. Some people may realize the error of their ways and correct their practices - who can say?
It's well known that error reports that are commonly wrong are worse than no report at all.
First I don't think the error report is commonly wrong. Second, it will be almost impossible for the person who commits such an error to find it if/when it occurs.
The hashing idea is a lot closer to the mark.
Not in my 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.
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
I've noticed a similar dynamic with a few other Boost libraries recently.
There might be an explanation for that. I get feedback from people with questions about using the library. Much of it is via private email. This is quite a different group than those that inhabit this list. On the list I get a lot of concerns about about usages of the library in ways I never imagined. Also many of the commenters on the list have strong opinions driven by their particular application. I feel I have to be concerned about correctness, transparency, efficiency, portability, long comple times, etc. Many times someone is disappointed I don't include this or that change because it conflicts with one of these aspects which is uninportant to them. So everyone is disappointed at least to some extent. This is the root cause that larger libaries that lots of people have an interest in (e.g.units/dimensions) can't make progress in boost. (Serialization would fall into the category except for my particular personality features.)
-- 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:
Hmm I'll take a look.
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.
I'm not sure what the above means. 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).
Actually that's not even accurate. Forming a const reference to an object doesn't make the object const. The fact that this design makes you write something hard to explain might be a clue that it isn't helping.
The problem you had was the same as mine when writing the tests. The typical code was A a, a1; text_archive oa(..) oa << a; ... text_iarchive ia(..) oa >> a1 BOOST_CHECK(a == a1) Of course this was easy to fix (just make use const A a1) but other cases required a little more work - but never very much. But I argue - as Joaquin did. That the above situation is not at all typical and that in typically the situation almost never comes up. Of course that is speculative on my part. But so far I've only gotten objections from library testers. Vladimir came up with a bunch of cases but they seemed very atypical to me. The were at best usages of the library in ways that have never occurred to me so it was hard for me to be convinced. That's why I say I believe its been blown waaaay out of proportion.
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...
typically that's the way it gets used anyway. Which is exactly my point.
Yah. Just another pointless hoop to jump through.
Yeah - just like the whole "const" business in the first place? For what its worth there are a couple of incidental aspects of this situation that might be interesting. a) This whole thing is implemented by one STATIC_ASSERT in oserializer.hpp which can be commented out b) I considered using STATIC_WARNING but I could never really quite STATIC_WARNING to function totally to my taste. c) After I ran this with my own tests, and being forced to think about each instance, I concluded that my code was more fragil than I had thought and became more convinced that it was a good idea. d) Also having to find my own errors in serialization of stl containers convinced me it was a good idea. I would like to wait and see how this works for a while. So far I've heard from myself - library writer Jeff - wrote serialization test for date/time Joaquin - wrote serialization for mult-index - a tricky job Vladimir - using in in real code. Dave - not used the library in any way As far as I'm concerned we really have only one data pont (Vladimir) which really addresses what the discussion is about. So lets relax a bit and let some more experience trickle in for a while and see what happens. Robert Ramey