Boost logo

Boost :

Subject: Re: [boost] [type_traits] is_base_of<B, D> should work when B is incomplete
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2016-03-04 04:41:03


2016-03-04 10:24 GMT+01:00 John Maddock <jz.maddock_at_[hidden]>:

>
> I have an incomplete type boost::in_place_factory. I want to check if a
>>> given type T is either derived from boost::in_place_factory. It doesn't
>>> have to be very strict: it can get false negative on multiple
>>> inheritance;
>>> it can give a false positive when T is implicitly convertible to
>>> boost::in_place_factory by other means, or simply return false_type when
>>> boost::in_place_factory is incomplete.
>>>
>>> Perhaps there is a C++03-compatible solution to this particular problem?
>>>
>>> Actually, I do not even need a true-false answer; I just need to disable
>> an
>> overload (in SFINAE sense) if boost::in_place_factory is either incomplete
>> or not a base class of T.
>>
>
> This may be fixable (or alternatively the fix may just break a ton of
> things.... we'll see), but I'm curious why in_place_factory needs to be
> incomplete - surely if you handle that base class a special case then you
> need it's definition anyway? In any case why not just include the header
> and be done with?
>
> Thanks, John.

This used to be an option, until we introduced the concept of Boost library
dependencies.

If I include a header with an empty definition of boost::in_place_factory_base,
I introduce a dependency between Boost.Optional and Boost.Utility. And
hardly anyone will need it, as the functionality offered by in-place
factories is obsolete in C++11.

boost::in_place_factory_base is meant only to be a "tag": if you derive
from it we trigger a special path for your type.

It is interesting that my problem only occurs on these experimental
oracle-sparc-S2-12.5-cpp11
<http://www.boost.org/development/tests/develop/oracle-sparc-S2-12-5-cpp11.html>
It implements rvalue references, decltype, variadic templates, but no
type_traits.

Regards,
&rzej


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk