Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-04-30 01:27:58

Jeff Garland wrote:
> Kim Barrett wrote:
>> At 4:40 PM -0700 4/29/07, Jeff Garland wrote:
>>> Domenico Andreoli wrote:
>>> diff -ur -x .svn
>>> ../boost-1.34.0-beta1/boost/archive/polymorphic_oarchive.hpp
>>> ./boost/archive/polymorphic_oarchive.hpp
>>> +
>>> + virtual ~polymorphic_oarchive() {}
>> For what it's worth, I've been maintaining a similar local patch
>> against 1.33.1 and have determined that it needs to be applied to
>> 1.34.0
>> as well. Below is the comment associated with the patch:
>> + // kab, 9/26/06: Avoid destructor slicing when using
>> polymorphic archives, + // where clients may not know the precise
>> type. The need for this was + // reported to Robert Ramey (via
>> boost developers list), where he + // acknowledged the problem
>> and said he would fix in a future release. + virtual
>> ~polymorphic_iarchive() { /* nothing to do here */ }
>> I believe that date was post-RC_1_34_0 branch, and in fact I think at
>> the time it was thought that boost 1.34.0 was immanent.
>> Hm. But reviewing the email thread I see that Robert ultimately
>> decided not to make this change, for reasons that I didn't (and still
>> don't) understand (and apparently forgot to pursue). See:

The above email says:

"Well, that's what I thought. Then I looked into it. When I tried it
I got problems due the the fact that the most derived class is
derived from multiple bases. see
It's easy to see by making the change to "virtual" with your original

That's what I still think.

> I don't really understand this at all. I thought the whole point of
> polymorphic_text_*archive was so you could derive from it and
> re-implement the various load/save methods. The whole point being
> that you can write your
> own format and use runtime dispatch ala classical
> serialization...after a quick look, though I guess I don't understand.

The "default" method of implementing serialization is via the CRTP
whereby calls to the implementation are resolved at compile time.
This should give the compiler the opportunity to generate the
most efficient code without the need to generate/instantiate code
for those functions never called.

The problem with this is that the serialization code has to be regenerated/
reinstantiated for each different archive. The results in more code
being generated. Also there are cases where we would like to
write generate an immutabel runtime interface so that programs/libraries
don't have be recompiled for every new archive. This would permit
things like dlls to contain serialization code that would work with
any archive past, present and/or future.

The "polymorphic" code is really a wrapper changing any archive
implemented with the CRTP pattern into a more traditional
virtual function pattern. All the archives in the library are implemented
by means of CRTP and the polymorphicautomatically generated.
This gives users the choice of using compile time polymorphism
or runtime polymorphism. I knew I could never enough get agreement
on which to use through a review so I just gave up and did both. I
used the "wrapper/converter" idea to make the job simpler.

I would recommend that those implement thier own archives from
scratch or derivation follow the same idea. That is, use CRTP
and implement the standard archive interface. Then create a
polymorphic version automatically as I have done.

>> So I would suggest that this might not be a simple and obviously safe
>> change for boost 1.34.0.

> Actually I find it hard to see how it will do any harm either. The
> class already has a virtual table so it can't increase the size of an
> instance. The accessibility isn't changed. I guess Robert will need
> to explain...

I made the suggested change and started to have problems which
I reported at the time. Now I forget the details. Anyone interested
could easily re-run the test with the change.

Robert Ramey

> Jeff
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at