Jarl Lindrud wrote:
I see this issue has now been closed, without a fix.
In my view it's a pretty serious bug, that this code:
std::vector<char> v0(25, 'A'); std::vector<char> v1;
std::ostringstream ostr; boost::archive::text_oarchive(ostr) & v0;
std::istringstream istr(ostr.str()); boost::archive::text_iarchive(istr) & v1;
bool ok = (v0 == v1);
, will fail, because of implicit compile-time instantiation in a completely different part of the program. For the typical user, this is next to impossible to diagnose, let alone understand. I guess I don't see how this can be thought of as a design feature.
I would have thought it would be possible to include sufficient metadata in the output archive, so that B.Ser. is able to correctly deserialize its own output archives, without depending on implicit compile-time instantiation.
For collections of primitive types like vector<char> the implementation level was set to "object_serializable". The suppresses inclusion of class information in the archive itself which leads to the the problem shown by your example. Perhaps it was a mistake to do this. But for every person who would conclude that, there is at least one person who would conclude that in this case efficiency would be an overriding concern in this instance. So its a no-win situation for me. If you think it's obvious that the wrong decision was made, consider the following: a) In order for a situation described in your example to arise in real life code, a program which saves data would have to include something like ar << ptr while the program which loads data could not include something like ar >> ptr. Were this the case, serialization has been broken in any case so I don't see how the situation in your example could ever arise in real code. FWIW, you're the first person ever to report this type problem. Of course, now I'm a little bit intrigued how you came upon this in the first place. b) the setting of "object_serializable" is the default. One make a derived class override it.
Sure, that would change the archive format, but it would hardly be the first such change, so I would think whatever backwards compatibility scheme is already in place, could deal with this as well.
If we were convinced that this had to change, it could be dealt with. Even if I were convinced that the original decision was not the optimal one, (which I'm not - though I could be), I would still have to be convinced that the situtuation were so non-optimal that it would be worth the trouble to address it. On a regular basis, I get "complaints" that the archive contains "too much" superfluous information. Basically, I can't please everyone. I tried to make reasonable defaults and provide a mechanism for overriding these defaults. That's the best I can do. Robert Ramey