[boost] Re: Re: serialization: review

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-04-20 19:53:23

"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:20040420155911.280A431574_at_acme.west.net...
[snip]
| > can the line "ar & boost::serialization::base_object<mammal>( *this )"
| > be put in a base-class like this
|
| > mammal::serialize( Archive& ar, unsigned version ) {
| >         ar & boost::serialization::base_object<mammal>(*this);
| >         do_serialize( ar, version );
| >         // virtual function that does the rest
| > }
|
| > to remove some redundancy?
|
| The intention of base_object is really to cast to the base class (and
| register the base/derived relationship).  So it its out of place here. The
| real issue is do_serialize. Is that supposed to be a virtual function?
With
| a templated argument? Maybe you want to consider this question a little
bit
| more.

then think of the do_serialize as an overloaded virual function. My point is
that
some might not want to have serialization stuff in a header.

| > | > I would like to see the focus shift from vector<T*> towards vector<
| > | > shared_ptr<T> > and ptr_vector<T>. using T* array[sz] or vector<T*>
| > | > is inherently unsafe if the pointers are heap-allocated.
| > |
| > | I believe that enforcing this is outside my role as a library creator.
|
| > ok, but I think you at least should point out very clearly the problems
in
| > it. Some non-experienced programmer might do what he sees in
| > documentation; therefore examples should encourage good style.
|
| Well, here is one programmer that needs to be better sold on this.
| Honestly, I don't think the serialization tutorial is the place to do it.

You're right in the sense that nowhere is the place to do it :-)

Anyway, I forgot to ask, what happens if I seralize a
std::list<T*> where the objects are not heap-allocated, but merely pointers
to other T's.? How do one control whether to heap-allocate or not?

| > | 3. const members uses a const-cast to re-init them. AFAICT, this is
| > | undefined behavior (cmp 7.1.5.1). I guess the need for serialization
| > | is just another reason for not having const members.
|
| Hmmm - what does re-init mean in this context?

"re-init" means assigning to a const member after it has been initialized.

| > | > this has come up from time to time.  I've tried to promote the view
| > | > that const members shouldn't be serialized but I couldn't convince
| > | > everyone.
| > | > I consider it outside my role as a library developer to try to
| > | > enforce this.
|
| > my point was that the examples given give undefined behavior so that
| > solution cannot be used.
|
| Which example gives undefined behavior?

this example below, unless I misunderstand 7.1.5.1 of the standard.
const Members
Saving const members to an archive requires no special considerations.
Loading const members can be addressed by using a const_cast:

    ar & const_cast<T &>(t);

| > | > 18. implementation of save_collection(). you cannot use unsigned int
| > | > count portably.
| > |
| > | I don't see this.
| > |
| > | > Instead you should use the new collection traits (reviewed after
| > | > this review) as follows:
| > |
| > | > typename boost::size_type_of< Collection >::type count = size( s );
| > |
| > | > then the code will also work for iterator views and arrays. Similar
| > | > comments apply to load_collection_impl.hpp
| > |
| > | I wanted to make the library buildable under 1.31 .
|
| > ok, then do
|
| > typename Collection::size_type count = s.size();
|
| > but don't assume Collection::size_type will be unsigned int.
|
| I'm not assuming that. I'm assuming that it will be convertible to an
| unsigned int and that an unsigned int will be large enough to hold any
| number of elements in an collection. Of course THAT might be rash
| assumption.

bingo.

| BTW where is the namespace Collection defined in 1.31 ?

I assumed the template parameter would be called that.

br

Thorsten