|
|
Boost Testing : |
From: John Maddock (john_at_[hidden])
Date: 2008-04-06 13:56:02
Robert Ramey wrote:
> OK I think I've figured out how these things are meant to be used and
> have altered boost/serialization/abstract.hpp in accordance with your
> suggestion.
>
> But I still get the same error
>
>>>>> // required by smart_cast for compilers not implementing
>>>>> // partial template specialization
>>>>> BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION(
>>>>> boost::archive::detail::basic_iarchive
>>>>> )
>
> The error message follows. I don't think its related to the
> is_abstract issue above
> it just looks that way because of the error message
Do you have a test case I can look at?
>>> That's not the way that macro is supposed to be used, it's an
>>> internal detail of the type_traits library such that: when defined
>>> it evaluates to the compiler intrinsic for the is_abstract trait,
>>> boost::is_abstract can simply it's implementation to just be in
>>> terms of BOOST_IS_ABSTRACT. However, when there is no compiler
>>> intrinsic, then the macro BOOST_IS_ABSTRACT *is not defined*, and
>>> boost::is_abstract uses it's own implementation methods.
>
> Its very unclear how this is meant to be used - if indeed it is meant
> to be used by library users at all.
What? BOOST_IS_ABSTRACT? That's not meant to be used by users, but folks
porting to new platforms:
http://svn.boost.org/svn/boost/trunk/libs/type_traits/doc/html/boost_typetraits/intrinsics.html
>>>>> a) Looking through the code in intrinsics.hpp it looks like at
>>>>> some point BOOST_IS_ABSTRACT(T) is defined so that is resolves to
>>>>> is_polymorphic. If my understanding of this is correct, its
>>>>> really a bad idea.
>>>
>>> No, but boost::is_abstract<> may equate to is_polymorphic<> if we
>>> can't implement is_abstract (but this only applies to old broken
>>> compilers). I seem to remember we had a long discussion about this
>>> when is_abstract was reviewed, and this came up as the least-worst
>>> solution.
>
> So it silently changes is_abstract to is_polymorphic a few levels down
> in very difficult to understand code - without so indicating to the
> user? Makes me wonder what the worst-worst solution was.
The worst case solution IMO is to indicate that a type is not abstract when
it is.
John.