Thorsten Ottosen wrote:
> Why isn't there a base class for all archieves? I think that would be
useful
> with class hierachies...for example, I need to implement two function and
> cannot use & anymore. Consider this
> struct mammal : boost::noncopyable
> {
> private:
> friend class boost::serialization::access;
> virtual void do_serialize( boost::archive::text_oarchive& ar, unsigned
> version ) = 0;
> virtual void do_serialize( boost::archive::text_iarchive& ar, unsigned
> version ) = 0;
> template< class Archive >
> void serialize( Archive & ar, unsigned version )
> {
> do_serialize( ar, version );
> }
> public:
> virtual const std::string& name() const = 0;
> virtual unsigned age() const = 0;
> virtual ~mammal() {}
> };
I don't understand the need for this. Given that mammal is an abstract base
class with no state variables of its own, it needs no serialization at all.
Just declare it as abstract using BOOST_IS_ABSTRACT(mammal). Only the
serialization of the derived classes need be specified.
> I can't figure out exactly how the library save/loads pointers when these
> cannot be allocated on the stack.
Please expand some more on this.
> a.. What is your evaluation of the documentation?
> I miss more specific type requirements. For example, is it necessary to
> have a default constructor? Is it necessary to be stack-allocable? Must
> the destructor be public?
Good point.
> I did try to extend the library to use my new smart containers; I was
> almost successful.
I would love to hear more about this. I would hope that it would easy to be
totally successful.
> 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.
> I tried to extend the library to support my smart containers, but I
> couldn't figure out what I did wrong. I think I might have saved them
> correctly, but I cannot figure out to load them. However, I do think that
> is a problem that can be solved together with Robert. (Robert, you can
> find the ptr_vector in the sandbox. If you could cast a glance on the
> code and tell me how the body of load_collection should look like, it
> would be great.)
I'll look at it.
Thorsten
> Some general nitpicks/comments (with these comments my test works on vc71,
> como4.3.3, g++3.3.1:
> 1. have you planned to use concept checks
I'm intrigued with concept checks for something like this but I havn't had
the time to spend on it.
> 2. documentation: can the width of the html be made adaptive to the window
> width? The right window must be scrolled to see it's contents which is
> annoying.
This drives me crazy also. Unfortunately, I haven't been able to figure out
what causes this. I believe it's a Microsoft IE issue - but who knows. I
would be grateful to anyone can explain to me how to fix this.
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.
> 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.
> 4. AFAICR, the use of placement new require proper alignment, so the
> object must eg. be heap-allocated. Is that guaranteed?
I believe this has been addressed. Objects allocated on the stack use
aligned storage to handle this.
> 5. I think the exception code should be returned by a function:
> exception_code code() const; this is how eg. the regex_error exception in
> tr1 will do it.
> 6. remove trailing comma in archive_exception.hpp: "unregistered_cast //
> base - derived relationship not registered with"
OK - though I don't think its an error.
> 7. archive/detail/basic_oarchive.hpp includes itself
Whoops.
> 8. is_abstract.hpp: there is something wierd about the is_abstact struct.
> uncommented the first part to be able to compile.
I don't see this.
> 9. serialization/serialization.hpp: why all the static casts?
> template<class Archive, class T>
> inline void serialize(
> Archive & ar, T & t, const BOOST_PFTO unsigned int file_version
>){
> access::serialize(ar, t, static_cast<const unsigned
int>(file_version));
> }
> AFAICT, they should be removed. Comeau has the follwing warning: type
> qualifier is meaningless on cast type
They wouldn't be there except they provide a work around for compilers which
do not support Partial Template Function Specialization. On conforming
compilers, the BOOST_PFTO resolves to nothing so the cast wouldn't be
necessary. So commeau is correct. I don't know how much effort I want to
invest to suppress benign warnings for specific compilers.
> 10. nvp.hpp: line 50:
> ar & t.value();
> There is on t-parameter.
OK - interesting the default implementation was never instantiated.
> 11. /archive/detail/oserializer.hpp", line 244: NULL reference is not
> allowed
> return * static_cast<const basic_pointer_oserializer *>(NULL);
^
> This not yet legal C++ (but the committee is changing that) use a static
> member and return that instead.
> Also, why all the static_casts?
In this case the reason is that when handling issues regarding preamble,
object-id, class id etc. the pointer to the object is handled as void * .
This permits the archive library to be pre-compiled and not have to be
recompiled for every instance. When such a void pointer is passed back to a
specific archive-type combination it has to be case back to the orginal type
to permit the calling of type serialization functions. This is really a
result reconciliation of conflicting goals.
a) serialization of pointers abstract and otherwise
b) serialization of pointers in a non-intrusive manner
c) limit pointless instantiation.
d) not require that user classes import headers related solely to
implementation.
For pointers this has generated a design which takes the typed pointer
converts it to void pointer, handles preamble and book keeping, converts it
back to typed pointer and (de)serializes the data. The requirement of
non-intrusiveness means we can't just pass around a base class pointer -
hence the need for casting.
> 12. two-phase lookup problems:
> /boost/archive/basic_text_oarchive.hpp", line 65: error #20:
> identifier "This" is undefined
> archive::save(* This(), t);
^
> Solution: prefix base class functions with this->.
I'm not sure I understand this but I don't see it doing any harm. If this
is a problem, the following would make more sense to me.
archive::save(* common_oarchive<Archive>::This(), t);
> remark: why is this->This()->XX() necessary? this->xx() should do it.
Hmm - I don't see this. save(Archive & ar, T t) is implemented in a more
derived class. Common_oarchive<Archive> rededirects it downward to that
class. I would expect this->xx() to give and undefined error. I could use
archive::save(* static_cast<Archive *>(this)t);
though I'm not sure you would find that anymore appealing.
> 13: archive/text_oarchive.hpp, similar lookup problems. this->newtoken(),
> this->delimiter = this->none;
as before - I don't see a problem but changing it doesn't hurt anything.
> 14: /archive/detail/basic_iarchive.hpp", line 46: error #20:
> identifier "basic_iarchive_impl" is undefined
> boost::scoped_ptr<basic_iarchive_impl> pimpl;
^
>solution: remember to forward declare basic_iarchieve_impl. Do the same for
>basic_oarchieve_impl.
OK - I had thought that using friend class made that unnecessary.
> 15: /archive/detail/archive_pointer_iserializer.hpp", line 42: error #284:
> (+detail/iserializer.hpp", line 240:)
> NULL reference is not allowed
> return *static_cast<const basic_iserializer *>(NULL);
^
> Solution: use a static member again.
> 16: two-phase lookup problems in archive/basic_text_iarchive.hpp",
> Solution: prefix by this->.
> 17. when you save_collection_impl.hpp (eg in vector.hpp) there is no need
> to specify template arguments again since they will be deduced.
I presume you mean that:
template<class Archive, class U, class Allocator>
inline void save(
Archive & ar,
const std::vector<U, Allocator> &t,
const unsigned int file_version
){
stl::save_collection<Archive, std::vector<U, Allocator> >(
ar, t
);
}
Can be replaced with:
template<class Archive, class U, class Allocator>
inline void save(
Archive & ar,
const std::vector<U, Allocator> &t,
const unsigned int file_version
){
stl::save_collection<Archive, std::vector>(
ar, t
);
}
But what about:
template<class Archive, class U, class Allocator>
inline void load(
Archive & ar,
std::vector<U, Allocator> &t,
const unsigned int file_version
){
stl::load_collection<
Archive,
std::vector<U, Allocator>,
stl::archive_input_seq<Archive, std::vector<U, Allocator> >,
stl::reserve_imp<std::vector<U, Allocator> >
>(ar, t);
}
This can't be replaced with:
template<class Archive, class U, class Allocator>
inline void load(
Archive & ar,
std::vector<U, Allocator> &t,
const unsigned int file_version
){
stl::load_collection<
Archive,
std::vector
stl::archive_input_seq<Archive, std::vector>,
stl::reserve_imp<std::vector>
>(ar, t);
}
Isn't a little bit of redundancy OK giving the alternative of having to keep
the details of deducibility in one's brain?
> 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 .
> 19. missing #include <boost/serialization/nvp.hpp> in serialization.hpp
Whoops - thanks.
Robert Ramey
