Re: [boost] [serialization] Compatibility between 1.32 and 1.33

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-07-05 17:22:21

Edward Diener wrote:

> Thanks for the explanation. Although I really dislike header file
> dependencies, the rule that you have about including archive headers
> before serialization headers is easy to understand.

> Regarding the partial specialization and no-RTTI problems, and without
> knowing your internal code, I would just like to suggest that for
> those
> using conforming compilers and RTTI you should strive not to impose
> the header file ordering rule of having the header archives files
> included
> before the header serialization files. I realize you are doing this,
> even in this case, anyway because the BOOST_CLASS_EXPORT("class")
> works properly with the rule, but I would still seek to eliminate
> this header

Its generally underestimated how much effort it takes to make something like
this work on a wide variety of platforms.  In order to accomplish this one
sometimes tries for the least common denominator.  Other times different
code is used for different platforms.  One fixed point that I tried to
maintain is that it be possible that one can write code that will work on
all platforms that boost supports. I viewed this as essential to permit
other library writers to serialization modules for their classes once and
only once.  This sort of supports the lowest common denominator approach
which I tend to favor.

> file dependency for conforming compilers and those who naturally use RTTI.

I should say I wasn't crazy about providing an alternative to RTTI.  But I
ended up doing it for a couple of reasons.  I had a list of criticisms to
address from the first rejection.  There were a number of other criticism
that I wasn't crazy about addressing either.  But in addressing each of
these one by one, I came to change my mind and see them as better ideas and
making a better package.  The last one was no-rtti.  I thought this was
really not worth the effort but then I thought - hmmm, that's what I thought
about the others also.  So, I'll experiment and see what happens.  I
factored out the extended_type_info code as separate header and
implementation and made a non-rtti implementation.  I still wasn't convinced
it was a valuable feature.  But it did isolate a fundamental piece in a more
logical, and understandable and modular piece.  So I left it it.  It turns
out that this plays a key part in "user" code - new serialization of
shared_ptr so now I have to add extended_type_info to the documentation -
sort of pain.  I don't have a real point here.  I'm just trying to convey
how things get to where they are and how its not always easy to make a
concise rationale for the way things are.

> Do not think, by saying the above, I do not applaud your heroic
> efforts to get serialization to work with non-conforming compilers and
> those people who prefer to turn off RTTI, but only that there must
> come  a point where those who use standard C++ should not face any of the
> restrictions of those who do not. Not that it is necessarily the
> programmer's fault that their compiler is deficient, or that they must
> not use RTTI for some reason, but I consider both non-standard C++.

For better or worse, this is a feature of the boost process.  In order to
get a library accepted, almost every requested requirement has to be
accomodated  unless it directly conflicts with some other requested feature.
Net result is a library which covers far more than any one programmer or
project needs.  When someone makes a "strong" case for a some arcane but
hard to implement "feature", there is no one (other than the library author)
with a strong case for not doing it.  And the library ends up including
almost everything. (Oh don't forget compile time and run-time performance as
well)  The difficulty of getting a library accepted grows disproportionatly
to its size and the number of people that might be interested in it.  I'm
not saying this is necessarily a bad thing.  That's just the way it is.

> As a long shot, and again not knowing the internals, is it not
> possible
> to have BOOST_CLASS_EXPORT("class") work as each archive is included,
> perhaps by including export.h at the end of each of your own archives
> and building the exported information one at a time ? No I am not
> trying
> to create extra work for you <g>, but just suggesting future
> possibilities to eliminate the very reasonable header file rule you
> have.

I never considered such an idea so its hard to comment on.  During the first
review there was a lot of objection that modules were way too big.  So I
made effort so that one only had to include what one used.  So one only has
to include export.hpp if and only if BOOST_CLASS_EXPORT is in fact being
used.  That's how we got here.

Robert Ramey