----- Mensaje original ----- De: Jeff Garland <jeff@crystalclearsoftware.com> Fecha: Sábado, Mayo 28, 2005 8:06 pm Asunto: Re: [boost] serializatation const change (was Re: Problem withserialization mersenne_twister with cvs)
On Sat, 28 May 2005 10:05:15 -0700, Robert Ramey wrote [...]
I don't see this change as "breaking code" but rather detecting code that is very likely already broken.
So, as I said, its not that I'm unsympathetic to your point of view, I just don't think everyone is sympathetic to mine.
Well, I'd say that 'no one' is sympathetic to yours, yet ;-) I don't think that Vladimir, myself, or the others that have posted on this topic are convinced that this change is really going to prevent people from making the error you are concerned about.
For the record, not that I'm in love with the stricter const rules either, but I must confess that, when hit by them the first time, they actually uncovered a (potential) problem in my test code. So... I've been thinking about this issue, and my impression is that regular code won't be hit as much as one might think. Typically, serialization is used like this in a program: class my_class { // add serialziation capabilities }; void save(const my class&) { // some file-opening work prior to actual saving ... } void load(my_class&) { // some file-opening work prior to actual loading ... } A typical program will have a centralized point of usage of serialization, and the usual const-abiding rules won't collide with Boost.Serialization. Now, a test program like the ones we've been writing to check the serialization capabilities of our libs is more likely to follow this pattern: std::ofstream ofs(..); archive::text_oarchive oa(ofs); my_class_1 c1; ... my_class_n cn; ... oa<<c1; ... oa<<cn; std::ifstream ifs(..); archive::text_iarchive ia(ofs); my_class_1 cc1; ... my_class_n ccn; ... ia>>cc1; ... ia>>ccn; BOOST_CHECK(c1==cc1); ... BOOST_CHECK(cn==ccn); and here we *do* run into the const problem. The key difference is that, in the latter pattern of usage, we are creating local classes just to check whether they're properly archived and restored. In a real program, the serialization code is typically provided a class to archive from the outside, as serializating classes created on the fly doesn't make much sense after all. Get my point? So, to sum it up, although I think stricter const rules won't prevent as many problems as desired, I think most users won't notice anyway. We lib testers belong to a different flock. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo