From: Robert Ramey (ramey_at_[hidden])
Date: 2006-12-17 18:29:51
Emil Dotchevski wrote:
> I don't think it is unreasonable to require that users register each
> class and archive type before they use them together.
I'm not the person that has to be convinced. Frankly it was easier
to implement the functionality than to convince a large number
of people that such functionality wasn't necessary.
> If portability is not
> a problem for someone, they can stick this registration in a global
> object in the cpp file that defines the class, and suffer later when
> they port to another system.
I don't think they will suffer any with the compilers we've seen so far.
> Even if portability was not an issue, I would still do the
> registration "manually".
Note that there is nothing preventing you from doing this. In fact in
some special cases, it is actually required - see demo_pimple.
> I don't think the author of class foo should
> be the one who decides whan archives will be used to serialize
> objects of class foo.
I don't think so either and I don't think the current implementation
> Besides, what if I want to use class foo but I
> will never serialize it? The physical coupling introduced by the
> "automatic" registration will link all kinds of dead code to my
> executable. No, thanks.
Actually this doesn't occur. Code is only generated for those
archives, and only those archives. whose headers are included.
The only "dead code" is for those classes "exported" and
serialized with a particular archive class. The code is there
but may never be called. But its unknowable at the translation
unit level so it has to bethere in case some other translation
unit creates one of these things to be serialized. So its not
even clear that "dead code" is the correct thing to call it.
Maybe its only dead code because most optimizers work
at the translation unit level. But even global optimizers can't
know what some DLL is going to create - etc.
Honestly, I think there are more subtilties to this question
than first apprears and I think that a deeper examination would
lead one to the conclusion that most of them are handled
by the library in an effective, practical and correct manner.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk