From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-08 02:41:07
Vladimir Prus wrote:
> Robert Ramey wrote:
>> Could you send a little more context. This isn't happening in our
> Just try a file containing two lines:
> #include <boost/type_traits/is_abstract.hpp>
> #include <boost/archive/binary_iarchive.hpp>
I see the problem now.
> Why serialization/is_abstract.hpp is in better position to handle such
> compilers then type_traits/is_abstract.hpp? I'm not saying that my
> is ideal, but having two headers for the same purpose is very bad
> idea, IMO.
Its just an oversight which requires some thought to fix. A little
a) I need a type trait to determine whether or not a base class could be
instanticiated. I believe I needed this to implement base_object.
b) I found and implementation of is_abstract. It was interesting but only
worked on some compilers. So I made serialization::is_abstract which
defaulted to false. For compilers not supporting is_abstract and for
portable code, is_abstract has to be overloaded.
c) eventually, is_abstract got fixed up in such a way that for compilers not
supporting it, it returns the result of is_polymorphic. I missed the
So it has come to pass that the type_traits is_abstract and serialization
is_abstract are different and have different defaults for non-conforming
compilers. I only just found out about this problem, and I haven't had time
to think about how to address it.
Of course the type traits implementation isn't going to be very useful given
that it silently gives the wrong result for many compilers. From my
perspective, it would have been better to static assert if one tried to use
is_abstract default on a non-conforming compiler.
The problem should only occur in modules which include both serialization
and type traits is_abstract. That fact might be of some consolation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk