[type_traits] Rewrite and dependency free version

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
119 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

[type_traits] Rewrite and dependency free version

John Maddock-3
I'm going to throw this out there to see what folks think:

In a branch called "Version2", see
https://github.com/boostorg/type_traits/tree/Version2 is a partially
rewritten type_traits lib: it doesn't yet contain all the traits of the
old one, but there's a pretty good selection to test.

The main pros for this version are:

1) Zero dependencies other than Boost.Config.
2) No horrible macro-obfuscation - all "real code", making it easier to
read and maintain.
3) Substantially reduced template instantiations where practical - often
half as many as before.
4) Substantially reduced #includes - the aim is that all files should
include only what they need and no more - with what's needed determined
by the actual implementation variant when appropriate.  There were also
a lot of spurious #includes left over from old workarounds no longer used.

The main cons:

1) I don't know what I've broken, but surely something, you can help by
testing but I would guess we would never be 100% sure it's all right
until it's out in the field.  This is the main reason for avoiding this
until now.
2) MPL interoperability should still work, but files which expect
type_traits headers to have included mpl ones will be broken unless they
explicitly include what they need.
3) Current MPL inter-operability is fragile see
https://github.com/boostorg/type_traits/blob/Version2/include/boost/type_traits/integral_constant.hpp
4) Function dispatching to an mpl::bool_ involves an (inline) function
call where as the old inheritance scheme did not.  This should mostly
disappear once optimizations are turned on, but is still a potential
issue for some folks I suspect.
5) I haven't got to the "difficult" headers like common_type.hpp yet.
6) Whatever I've forgotten ;)

Of course (2), (3) and (4) could be solved by making mpl's bool.hpp some
kind of "core" header.

So... what I need from you kind folks is:

* Is this the right way forward?
* Can you test with your favourite compilers and compare with results
for develop - So far I've tested with msvc-10,11,12,14  Intel 14,15,
GCC-4.5.4...4.9.1, plus a reasonably recent clang.
* If anyone would like to help converting further traits all help would
be much appreciated.... Oh and the compiler requirements in the docs are
all wildly out of date too...

Regards, John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Stephen Kelly-2
John Maddock wrote:

> So... what I need from you kind folks is:
>
> * Is this the right way forward?

Thanks for your work on this!

I haven't looked into it yet but I will, and I'll see where I can help.

Do you intend this to replace the current type_traits implementation, or do
you expect a future version of boost to ship both?

Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

John Maddock-3
>> So... what I need from you kind folks is:
>>
>> * Is this the right way forward?
>
> Thanks for your work on this!
>
> I haven't looked into it yet but I will, and I'll see where I can help.
>
> Do you intend this to replace the current type_traits implementation, or do
> you expect a future version of boost to ship both?

Originally I was thinking of shipping both with the new as the default,
and a "legacy" version for those who need it.  But as I haven't found
any breakages... yet.... I'm hoping that may not be needed.  We'll see.
  Whatever, any transition would have to be very carefully handled.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Ion Gaztañaga
In reply to this post by John Maddock-3
El 14/01/2015 a las 20:58, John Maddock escribió:
> I'm going to throw this out there to see what folks think:
>
> In a branch called "Version2", see
> https://github.com/boostorg/type_traits/tree/Version2 is a partially
> rewritten type_traits lib: it doesn't yet contain all the traits of the
> old one, but there's a pretty good selection to test.

Very nice.
> The main pros for this version are:
>
> 1) Zero dependencies other than Boost.Config.

We still have Boost.PP.

> 4) Substantially reduced #includes - the aim is that all files should
> include only what they need and no more - with what's needed determined
> by the actual implementation variant when appropriate.  There were also
> a lot of spurious #includes left over from old workarounds no longer used.

For "is_function", you might test (I could help once things are
stabilized) another approach that could avoid the use of Boost.PP:

//For a function to pointer an lvalue of function type T
//can be implicitly converted to a prvalue
//pointer to that function. This does not apply to
//non-static member functions because lvalues
//that refer to non-static member functions do not exist.
template <class T>
struct is_reference_convertible_to_pointer
{
    struct twochar { char dummy[2]; };
    template <class U> static char    test(U*);
    template <class U> static twochar test(...);
    static T& source();
    static const bool value = sizeof(char) == sizeof(test<T>(source()));
};
//Filter out:
// - class types that might have implicit conversions
// - void (to avoid forming a reference to void later)
// - references (e.g.: filtering reference to functions)
// - nullptr_t (convertible to pointer)
template < class T
          , bool Filter = is_class_or_union<T>::value  ||
                          is_void<T>::value            ||
                          is_reference<T>::value       ||
                          is_nullptr_t<T>::value       >
struct is_function_impl
{  static const bool value =
is_reference_convertible_to_pointer<T>::value; };

template <class T>
struct is_function_impl<T, true>
{  static const bool value = false; };

template <class T>
struct is_function
    : is_function_impl<T>
{};

This could allow us to avoid the preprocessor also in
"is_member_function_pointer":

template <class T>
struct is_member_function_pointer_cv
{
    static const bool value = false;
};

template <class T, class C>
struct is_member_function_pointer_cv<T C::*>
    : is_function<T>
{};

template <class T>
struct is_member_function_pointer
     : is_member_function_pointer_cv<typename remove_cv<T>::type>
{};

Best,

Ion

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Edward Diener-3
In reply to this post by John Maddock-3
On 1/14/2015 2:58 PM, John Maddock wrote:
> I'm going to throw this out there to see what folks think:
>
> In a branch called "Version2", see
> https://github.com/boostorg/type_traits/tree/Version2 is a partially
> rewritten type_traits lib: it doesn't yet contain all the traits of the
> old one, but there's a pretty good selection to test.

How do I get this version in my local modular boost to test ? Won't it
conflict with the type_traits already there if I just clone it directly ?

>
> The main pros for this version are:
>
> 1) Zero dependencies other than Boost.Config.
> 2) No horrible macro-obfuscation - all "real code", making it easier to
> read and maintain.
> 3) Substantially reduced template instantiations where practical - often
> half as many as before.
> 4) Substantially reduced #includes - the aim is that all files should
> include only what they need and no more - with what's needed determined
> by the actual implementation variant when appropriate.  There were also
> a lot of spurious #includes left over from old workarounds no longer used.
>
> The main cons:
>
> 1) I don't know what I've broken, but surely something, you can help by
> testing but I would guess we would never be 100% sure it's all right
> until it's out in the field.  This is the main reason for avoiding this
> until now.
> 2) MPL interoperability should still work, but files which expect
> type_traits headers to have included mpl ones will be broken unless they
> explicitly include what they need.

Anyone who assumes header files will be included, rather then include
what's needed, for any C++ software deserves to be broken.

> 3) Current MPL inter-operability is fragile see
> https://github.com/boostorg/type_traits/blob/Version2/include/boost/type_traits/integral_constant.hpp
>
> 4) Function dispatching to an mpl::bool_ involves an (inline) function
> call where as the old inheritance scheme did not.  This should mostly
> disappear once optimizations are turned on, but is still a potential
> issue for some folks I suspect.
> 5) I haven't got to the "difficult" headers like common_type.hpp yet.
> 6) Whatever I've forgotten ;)
>
> Of course (2), (3) and (4) could be solved by making mpl's bool.hpp some
> kind of "core" header.
>
> So... what I need from you kind folks is:
>
> * Is this the right way forward?
> * Can you test with your favourite compilers and compare with results
> for develop - So far I've tested with msvc-10,11,12,14  Intel 14,15,
> GCC-4.5.4...4.9.1, plus a reasonably recent clang.

I can test with some earlier versions of gcc as well as msvc-8 and
msvc-9 as soon as I get the branch.

> * If anyone would like to help converting further traits all help would
> be much appreciated.... Oh and the compiler requirements in the docs are
> all wildly out of date too...



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Edward Diener-3
On 1/14/2015 7:17 PM, Edward Diener wrote:

> On 1/14/2015 2:58 PM, John Maddock wrote:
>> I'm going to throw this out there to see what folks think:
>>
>> In a branch called "Version2", see
>> https://github.com/boostorg/type_traits/tree/Version2 is a partially
>> rewritten type_traits lib: it doesn't yet contain all the traits of the
>> old one, but there's a pretty good selection to test.
>
> How do I get this version in my local modular boost to test ? Won't it
> conflict with the type_traits already there if I just clone it directly ?

Ignore. Tortoise Git, which I use on Windows, didn't see the branch
until I browsed the log. Then i was able to switch and track it.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Peter Dimov-2
In reply to this post by John Maddock-3
John Maddock wrote:
> I'm going to throw this out there to see what folks think:

They very much approve of, and thank you for, your work. :-) This is so much
better. :-)

> In a branch called "Version2", see
> https://github.com/boostorg/type_traits/tree/Version2 is a partially
> rewritten type_traits lib: it doesn't yet contain all the traits of the
> old one, but there's a pretty good selection to test.

I wonder why you have decided to return a reference to mpl::bool_, instead
of just ("stupidly") returning by value. Compilers like "stupid" code, they
optimize it better. Typically, the use case is:

void f( mpl::true_ );
void f( mpl::false_ );

f( is_pointer<X>() );

and if you return by value, it can construct directly into the argument,
whereas by reference it needs to use the copy constructor.

That said, I still think that it may be better to add the conversion on the
MPL side; this will obviate the need for the fragile forward declarations
(and it will support any integral constants, not just this one).

We can, of course, in addition add a converting constructor to
integral_constant as well, so that the "officially blessed" way to dispatch
would be on true_type and false_type. This dispatch will work on std::
traits as well.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Edward Diener-3
In reply to this post by John Maddock-3
On 1/14/2015 2:58 PM, John Maddock wrote:

> I'm going to throw this out there to see what folks think:
>
> In a branch called "Version2", see
> https://github.com/boostorg/type_traits/tree/Version2 is a partially
> rewritten type_traits lib: it doesn't yet contain all the traits of the
> old one, but there's a pretty good selection to test.
>
> The main pros for this version are:
>
> 1) Zero dependencies other than Boost.Config.
> 2) No horrible macro-obfuscation - all "real code", making it easier to
> read and maintain.
> 3) Substantially reduced template instantiations where practical - often
> half as many as before.
> 4) Substantially reduced #includes - the aim is that all files should
> include only what they need and no more - with what's needed determined
> by the actual implementation variant when appropriate.  There were also
> a lot of spurious #includes left over from old workarounds no longer used.
>
> The main cons:
>
> 1) I don't know what I've broken, but surely something, you can help by
> testing but I would guess we would never be 100% sure it's all right
> until it's out in the field.  This is the main reason for avoiding this
> until now.
> 2) MPL interoperability should still work, but files which expect
> type_traits headers to have included mpl ones will be broken unless they
> explicitly include what they need.
> 3) Current MPL inter-operability is fragile see
> https://github.com/boostorg/type_traits/blob/Version2/include/boost/type_traits/integral_constant.hpp
>
> 4) Function dispatching to an mpl::bool_ involves an (inline) function
> call where as the old inheritance scheme did not.  This should mostly
> disappear once optimizations are turned on, but is still a potential
> issue for some folks I suspect.
> 5) I haven't got to the "difficult" headers like common_type.hpp yet.
> 6) Whatever I've forgotten ;)
>
> Of course (2), (3) and (4) could be solved by making mpl's bool.hpp some
> kind of "core" header.
>
> So... what I need from you kind folks is:
>
> * Is this the right way forward?
> * Can you test with your favourite compilers and compare with results
> for develop - So far I've tested with msvc-10,11,12,14  Intel 14,15,
> GCC-4.5.4...4.9.1, plus a reasonably recent clang.

Testing gcc on Windows 7 with mingw and mingw64:

Running type_traits tests passed with msvc-8.0, msvc-9.0, gcc-4.4.0,
gcc-4.5.0, gcc-4.5.2, and gcc-4.9.2.

Failed with gcc-4.3.0 with:

"testing.capture-output
..\..\..\bin.v2\libs\type_traits\test\has_nothrow_assign_test.test\gcc-mingw-4.3.0\debug\has_nothrow_assign_test.run
====== BEGIN OUTPUT ======
has_nothrow_assign_test.cpp:204: The expression:
"::boost::has_nothrow_assign<nothrow_construct_UDT>::value" had an
invalid value (found 1, expected 0)"

In type_traits with gcc versions below 4 there are lots of failures of
the order of:

"gcc.compile.c++
..\..\..\bin.v2\libs\type_traits\test\is_virtual_base_of_test.test\gcc-mingw-3.4.5\debug\is_virtual_base_of_test.o
../../../boost/type_traits/is_virtual_base_of.hpp: In instantiation of
`boost::detail::is_virtual_base_of_impl<Base, Derived,
boost::integral_constant<bool,  true>
 >::boost_type_traits_internal_struct_X':
../../../boost/type_traits/is_virtual_base_of.hpp:65:   instantiated
from `boost::detail::is_virtual_base_of_impl<Base, Derived,
boost::integral_constant<bool,  true> >'
../../../boost/type_traits/is_virtual_base_of.hpp:73:   instantiated
from `boost::detail::is_virtual_base_of_impl2<Base, Derived>'
../../../boost/type_traits/is_virtual_base_of.hpp:82:   instantiated
from `boost::is_virtual_base_of<Base, Derived>'"

etc. Of course I can't imagine anyone still using those versions.

The function_types library depends on some type_traits implementation
which is not in Version2, and tti uses function_types etc so tti fails.

> * If anyone would like to help converting further traits all help would
> be much appreciated.... Oh and the compiler requirements in the docs are
> all wildly out of date too...

Where are the compiler requirements for type_traits mentioned ?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Beman Dawes
In reply to this post by John Maddock-3
On Wed, Jan 14, 2015 at 2:58 PM, John Maddock <[hidden email]> wrote:

> I'm going to throw this out there to see what folks think:
>
> In a branch called "Version2", see
> https://github.com/boostorg/type_traits/tree/Version2 is a partially
> rewritten type_traits lib: it doesn't yet contain all the traits of the old
> one, but there's a pretty good selection to test.
>
> The main pros for this version are:
>
> 1) Zero dependencies other than Boost.Config.
> 2) No horrible macro-obfuscation - all "real code", making it easier to read
> and maintain.
> 3) Substantially reduced template instantiations where practical - often
> half as many as before.
> 4) Substantially reduced #includes - the aim is that all files should
> include only what they need and no more - with what's needed determined by
> the actual implementation variant when appropriate.  There were also a lot
> of spurious #includes left over from old workarounds no longer used.

Every one of those is a big win.

>
> The main cons:
>
> 1) I don't know what I've broken, but surely something, you can help by
> testing but I would guess we would never be 100% sure it's all right until
> it's out in the field.  This is the main reason for avoiding this until now.
> 2) MPL interoperability should still work, but files which expect
> type_traits headers to have included mpl ones will be broken unless they
> explicitly include what they need.
> 3) Current MPL inter-operability is fragile see
> https://github.com/boostorg/type_traits/blob/Version2/include/boost/type_traits/integral_constant.hpp
> 4) Function dispatching to an mpl::bool_ involves an (inline) function call
> where as the old inheritance scheme did not.  This should mostly disappear
> once optimizations are turned on, but is still a potential issue for some
> folks I suspect.
> 5) I haven't got to the "difficult" headers like common_type.hpp yet.
> 6) Whatever I've forgotten ;)

Those don't seem like showstoppers, either individually or in
aggregate. Careful testing, and social engineering like announcing the
1.58 beta more widely than usually will help, too.

>
> Of course (2), (3) and (4) could be solved by making mpl's bool.hpp some
> kind of "core" header.
>
> So... what I need from you kind folks is:
>
> * Is this the right way forward?

+1.

The potential risks seem minor compared to the known gains.

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

John Maddock-3
In reply to this post by Edward Diener-3
> Testing gcc on Windows 7 with mingw and mingw64:
>
> Running type_traits tests passed with msvc-8.0, msvc-9.0, gcc-4.4.0,
> gcc-4.5.0, gcc-4.5.2, and gcc-4.9.2.
>
> Failed with gcc-4.3.0 with:
>
> "testing.capture-output
> ..\..\..\bin.v2\libs\type_traits\test\has_nothrow_assign_test.test\gcc-mingw-4.3.0\debug\has_nothrow_assign_test.run
>
> ====== BEGIN OUTPUT ======
> has_nothrow_assign_test.cpp:204: The expression:
> "::boost::has_nothrow_assign<nothrow_construct_UDT>::value" had an
> invalid value (found 1, expected 0)"

I assume the current version has the same failure?

> In type_traits with gcc versions below 4 there are lots of failures of
> the order of:
>
> "gcc.compile.c++
> ..\..\..\bin.v2\libs\type_traits\test\is_virtual_base_of_test.test\gcc-mingw-3.4.5\debug\is_virtual_base_of_test.o
>
> ../../../boost/type_traits/is_virtual_base_of.hpp: In instantiation of
> `boost::detail::is_virtual_base_of_impl<Base, Derived,
> boost::integral_constant<bool,  true>
>  >::boost_type_traits_internal_struct_X':
> ../../../boost/type_traits/is_virtual_base_of.hpp:65:   instantiated
> from `boost::detail::is_virtual_base_of_impl<Base, Derived,
> boost::integral_constant<bool,  true> >'
> ../../../boost/type_traits/is_virtual_base_of.hpp:73:   instantiated
> from `boost::detail::is_virtual_base_of_impl2<Base, Derived>'
> ../../../boost/type_traits/is_virtual_base_of.hpp:82:   instantiated
> from `boost::is_virtual_base_of<Base, Derived>'"
>
> etc. Of course I can't imagine anyone still using those versions.

You missed out the error message!  But again, does the current version
have the same failure?

> The function_types library depends on some type_traits implementation
> which is not in Version2, and tti uses function_types etc so tti fails.
>
>> * If anyone would like to help converting further traits all help would
>> be much appreciated.... Oh and the compiler requirements in the docs are
>> all wildly out of date too...
>
> Where are the compiler requirements for type_traits mentioned ?

There are out of date mentions in the docs - it all needs a *lot* of
revising.

If you mean "what are the requirements for this rewrite", then I don't
know yet... *should* be the same as the current code modulo the usual
SNAFU's

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

John Maddock-3
In reply to this post by Peter Dimov-2
>> In a branch called "Version2", see
>> https://github.com/boostorg/type_traits/tree/Version2 is a partially
>> rewritten type_traits lib: it doesn't yet contain all the traits of
>> the old one, but there's a pretty good selection to test.
>
> I wonder why you have decided to return a reference to mpl::bool_,
> instead of just ("stupidly") returning by value. Compilers like "stupid"
> code, they optimize it better. Typically, the use case is:

It was the only way to break the dependency to MPL (without modifying
MPL that is).  Can't return a forward declaration by value...

> void f( mpl::true_ );
> void f( mpl::false_ );
>
> f( is_pointer<X>() );
>
> and if you return by value, it can construct directly into the argument,
> whereas by reference it needs to use the copy constructor.
>
> That said, I still think that it may be better to add the conversion on
> the MPL side; this will obviate the need for the fragile forward
> declarations (and it will support any integral constants, not just this
> one).
>
> We can, of course, in addition add a converting constructor to
> integral_constant as well, so that the "officially blessed" way to
> dispatch would be on true_type and false_type. This dispatch will work
> on std:: traits as well.

+1.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

John Maddock-3
In reply to this post by Ion Gaztañaga
> Very nice.
>> The main pros for this version are:
>>
>> 1) Zero dependencies other than Boost.Config.
>
> We still have Boost.PP.

No, just to be clear: *there is absolutely no dependency on the PP lib*.

It is true that there are a couple of headers which have a "maintenance
mode" that includes PP headers - but the result needs a search and
replace afterwards to produce valid C++ code.  No user code can ever
include a PP header via type_traits.  Ever.

To make this clearer, one thing I considered was archiving the PP
generating code somewhere, and removing it from the headers.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Frédéric Bron
In reply to this post by John Maddock-3
Hi John,

> 2) No horrible macro-obfuscation - all "real code", making it easier to read
> and maintain.

Do you see any possibility/need to replace the use of macros in the
operator traits (has_plus, has_less...)? They do basically all the
same thing and I do not see how to change that. I do not think
duplicating the code would be a good option.
Cheers,

Frédéric

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Ion Gaztañaga
In reply to this post by John Maddock-3
El 15/01/2015 a las 10:04, John Maddock escribió:

>> Very nice.
>>> The main pros for this version are:
>>>
>>> 1) Zero dependencies other than Boost.Config.
>>
>> We still have Boost.PP.
>
> No, just to be clear: *there is absolutely no dependency on the PP lib*.
>
> It is true that there are a couple of headers which have a "maintenance
> mode" that includes PP headers - but the result needs a search and
> replace afterwards to produce valid C++ code.  No user code can ever
> include a PP header via type_traits.  Ever.
>
> To make this clearer, one thing I considered was archiving the PP
> generating code somewhere, and removing it from the headers.

Ah! Sorry, I see what you say. In any case with my alternative
implementation you could avoid even Boost.PP for manteinance and avoid
all those overloads.

In any case, this should be a possible improvement for the future.

Many thanks for the explanations

Ion

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Peter Dimov-2
Ion Gaztañaga wrote:

> In any case with my alternative implementation you could avoid even
> Boost.PP for manteinance and avoid all those overloads.

My first thought when looking at is_function was also to suggest
"is_convertible<T&,T*>", but then I saw that Ion has already got to it
first, complete with the nullptr_t check.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Agustín K-ballo Bergé
On 1/15/2015 11:34 AM, Peter Dimov wrote:
> Ion Gaztañaga wrote:
>
>> In any case with my alternative implementation you could avoid even
>> Boost.PP for manteinance and avoid all those overloads.
>
> My first thought when looking at is_function was also to suggest
> "is_convertible<T&,T*>", but then I saw that Ion has already got to it
> first, complete with the nullptr_t check.

This doesn't quite work as `void() const`, and any other combination of
cv and ref qualifiers, is a function type but cannot be instantiated.

Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Peter Dimov-2
Agustín K-ballo Bergé wrote:

> On 1/15/2015 11:34 AM, Peter Dimov wrote:
> > Ion Gaztañaga wrote:
> >
> >> In any case with my alternative implementation you could avoid even
> >> Boost.PP for manteinance and avoid all those overloads.
> >
> > My first thought when looking at is_function was also to suggest
> > "is_convertible<T&,T*>", but then I saw that Ion has already got to it
> > first, complete with the nullptr_t check.
>
> This doesn't quite work as `void() const`, and any other combination of cv
> and ref qualifiers, is a function type but cannot be instantiated.

You're right. The current PP-based implementation doesn't catch those
either, though. Fortunately, if a compiler supports 'void () const &&', it
probably has std::is_function as well, so we can just use that. :-)

Although, now that I think of it, creating 'void() const' is in principle
possible in C++03 as well. Not sure what the old type traits did with such
types.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Peter Dimov-2
> Although, now that I think of it, creating 'void() const' is in principle
> possible in C++03 as well. Not sure what the old type traits did with such
> types.

boost::is_function<void() const> says 0, even in C++11 mode.

#include <boost/type_traits/is_function.hpp>
#include <boost/core/demangle.hpp>
#include <iostream>
#include <typeinfo>

struct X
{
    void f() const {}
};

template< class T > struct Y
{
};

template< class C, class F > void test( F C::* /*pf*/ )
{
    std::cout << boost::core::demangle( typeid( F ).name() ) << std::endl;
    std::cout << boost::core::demangle( typeid( Y<F> ).name() ) <<
std::endl;
    std::cout << boost::is_function< F >::value << std::endl;
}

int main()
{
    test( &X::f );
}


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

John Maddock-3
>> Although, now that I think of it, creating 'void() const' is in
>> principle possible in C++03 as well. Not sure what the old type traits
>> did with such types.
>
> boost::is_function<void() const> says 0, even in C++11 mode.
>
> #include <boost/type_traits/is_function.hpp>
> #include <boost/core/demangle.hpp>
> #include <iostream>
> #include <typeinfo>
>
> struct X
> {
>     void f() const {}
> };
>
> template< class T > struct Y
> {
> };
>
> template< class C, class F > void test( F C::* /*pf*/ )
> {
>     std::cout << boost::core::demangle( typeid( F ).name() ) << std::endl;
>     std::cout << boost::core::demangle( typeid( Y<F> ).name() ) <<
> std::endl;
>     std::cout << boost::is_function< F >::value << std::endl;
> }
>
> int main()
> {
>     test( &X::f );
> }

Peter, can you file a bug report so this doesn't get lost?

I'm trying hard to *not* change semantics or implementation strategy at
this stage.  One thing at a time!

Thanks, John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [type_traits] Rewrite and dependency free version

Edward Diener-3
In reply to this post by John Maddock-3
On 1/15/2015 3:58 AM, John Maddock wrote:

>> Testing gcc on Windows 7 with mingw and mingw64:
>>
>> Running type_traits tests passed with msvc-8.0, msvc-9.0, gcc-4.4.0,
>> gcc-4.5.0, gcc-4.5.2, and gcc-4.9.2.
>>
>> Failed with gcc-4.3.0 with:
>>
>> "testing.capture-output
>> ..\..\..\bin.v2\libs\type_traits\test\has_nothrow_assign_test.test\gcc-mingw-4.3.0\debug\has_nothrow_assign_test.run
>>
>>
>> ====== BEGIN OUTPUT ======
>> has_nothrow_assign_test.cpp:204: The expression:
>> "::boost::has_nothrow_assign<nothrow_construct_UDT>::value" had an
>> invalid value (found 1, expected 0)"
>
> I assume the current version has the same failure?

You are correct. There is no difference between the current version and
Version2.

>
>> In type_traits with gcc versions below 4 there are lots of failures of
>> the order of:
>>
>> "gcc.compile.c++
>> ..\..\..\bin.v2\libs\type_traits\test\is_virtual_base_of_test.test\gcc-mingw-3.4.5\debug\is_virtual_base_of_test.o
>>
>>
>> ../../../boost/type_traits/is_virtual_base_of.hpp: In instantiation of
>> `boost::detail::is_virtual_base_of_impl<Base, Derived,
>> boost::integral_constant<bool,  true>
>>  >::boost_type_traits_internal_struct_X':
>> ../../../boost/type_traits/is_virtual_base_of.hpp:65:   instantiated
>> from `boost::detail::is_virtual_base_of_impl<Base, Derived,
>> boost::integral_constant<bool,  true> >'
>> ../../../boost/type_traits/is_virtual_base_of.hpp:73:   instantiated
>> from `boost::detail::is_virtual_base_of_impl2<Base, Derived>'
>> ../../../boost/type_traits/is_virtual_base_of.hpp:82:   instantiated
>> from `boost::is_virtual_base_of<Base, Derived>'"
>>
>> etc. Of course I can't imagine anyone still using those versions.
>
> You missed out the error message!

Just warnings and no error message.

>  But again, does the current version
> have the same failure?

The current version has similar failures. I don't see an error message
with the failures in either the current version or the version2 version
for gcc-3.4.5, just lots of warnings with "...failed gcc.compile.c++ ...
" messages. Are the type_traits tests set to fail if any warnings occur ?

It hardly seems necessary for type_traits to support gcc-3. I shouldn't
have bothered testing it anyway.

>
>> The function_types library depends on some type_traits implementation
>> which is not in Version2, and tti uses function_types etc so tti fails.
>>
>>> * If anyone would like to help converting further traits all help would
>>> be much appreciated.... Oh and the compiler requirements in the docs are
>>> all wildly out of date too...
>>
>> Where are the compiler requirements for type_traits mentioned ?
>
> There are out of date mentions in the docs - it all needs a *lot* of
> revising.

I could not find any mention of compiler requirements in the type_traits
docs, much less out of date mentions, other than in the topic "Support
for Compiler Intrinsics".

>
> If you mean "what are the requirements for this rewrite", then I don't
> know yet... *should* be the same as the current code modulo the usual
> SNAFU's



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234 ... 6