From: Robert Ramey (ramey_at_[hidden])
Date: 2007-03-19 12:51:12
Zach Laine wrote:
> Well, this went a little off-topic, but I still would like to know why
> Robert thinks that adding aliases is a bad idea. It seems to me that
> my mistake is a pretty likely one in the long term, and so the
> Serialization library needs to provide a way to recover from such
> mistakes, or reduce the chances of their introduction altogether (by
> removing BOOST_CLASS_EXPORT()). At the very least, if
> BOOST_CLASS_EXPORT() is to stay, an explicit note regarding this
> pitfall should be added to the docs. Again, I am happy to write a
> patch for the code and/or docs.
My first reaction is that its a bad idea. But I'm open to having my
mind changed. What I'm concerned about is the possibility that
adding such a feature would ripple down into the library making
it (even) more complex, harder to maintain, perhaps hurting
performance, etc. just to address a case which shouldn't
have occurred in the first place. So why don't we proceed
a) make the changes you need to make to address your
b) When we get a look at the changes, we can decide
whether they're simple and don't complicate the library
or whether it starts a whole chain reaction.
More interesting to me would be a way to somehow
trap this situation before it gets to this point. Something
An automatic serialization regression tester.
Every time the version number is incremented, a
(automatically generated?) test file is saved under
the name ... version-1. And the all the version
test files version-0 through version-n are read
back to verify that backward compatibility has been
Another idea would be that the exernal name
set with BOOST_CLASS_EXPORT be associated
with the current version number. I don't know
how that would effect things, but it might be
a long/deep ripple effect.
So its not that I'm really opposed in principle,
I just don't want to start mucking things up
to deal with one unusual case which
is the result of programmer error.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk