Le 26/05/15 23:46, Aparna Kumta a écrit :

On 05/22/15 05:22, John Maddock wrote:

...

A heads up that the "Version2" rewrite of type traits is now in develop.

There's still lots to do - more PR's will happen over the coming weeks to remove obsoleted code from other libraries (and quash the warnings that they'd otherwise generate). The docs also need a major update.

In the mean time please do shout loudly if there are any regressions caused by this change. I am seeing several test failures for Oracle Solaris Studio runs on develop branch as follows: http://www.boost.org/development/tests/develop/developer/output/oracle-sparc...

"CC" -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -errwarn -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -I"../libs/type_traits/test/libs/tt2/light/include" -c -o "/export/home/sstrunk-tester/boost_regression/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/type_traits/test/common_type_2_test.test/sun-stlport4/release/threading-multi/common_type_2_test.o" "../libs/type_traits/test/common_type_2_test.cpp"

"../boost/type_traits/common_type.hpp", line 116: Error: detail_type_traits_common_type is not defined. "../boost/type_traits/common_type.hpp", line 116: Error: A declaration does not specify a tag or an identifier. "../boost/type_traits/common_type.hpp", line 116: Error: Use ";" to terminate declarations. "../boost/type_traits/common_type.hpp", line 116: Error: "}" expected instead of"<".

Thanks for the report. I don't see where the error could be. Do you mind to provide the result of the preprocessor on a simple example?

In boost/type_traits/common_type.hpp , lines #15- #17, 15 #if defined(__SUNPRO_CC) && !defined(BOOST_COMMON_TYPE_DONT_USE_TYPEOF) 16 # define BOOST_COMMON_TYPE_DONT_USE_TYPEOF 17 #endif

However, __typeof__ is supported and this file needs to be modified to reflect that.

We will need a patch that works for the versions of SunPro providing __typeof__. But shouldn't this be part of Boost.Typeof? Could you provide such a patch? Vicente

John Maddock wrote:

On 27/05/2015 07:11, Vicente J. Botet Escriba wrote:

...

We will need a patch that works for the versions of SunPro providing __typeof__. But shouldn't this be part of Boost.Typeof? Could you provide such a patch?

Yes Boost.Typeof needs patching as well, ...

Boost.Typeof already appears to use __typeof__: #elif defined(__SUNPRO_CC) # if (__SUNPRO_CC < 0x590 ) # ifdef BOOST_TYPEOF_NATIVE # error native typeof is not supported # endif # ifndef BOOST_TYPEOF_EMULATION # define BOOST_TYPEOF_EMULATION # endif # else # ifndef BOOST_TYPEOF_EMULATION # ifndef BOOST_TYPEOF_NATIVE # define BOOST_TYPEOF_NATIVE # endif # define BOOST_TYPEOF_KEYWORD __typeof__ # endif # endif

... but note that since one goal of the rewrite is to reduce the libraries dependencies, Boost.Typeof is used as a last resort in common_type, and typeof is used directly when available.

Do we have to use Typeof in common_type at all? In the cases in which common_type::type is either T or U, can we not find that out by using two overloads? Is this not good enough?

John Maddock wrote:

...

Do we have to use Typeof in common_type at all? In the cases in which common_type::type is either T or U, can we not find that out by using two overloads? Is this not good enough?

Wouldn't that fail where promotions are involved for example with enum types?

Yes, it's not as I specified. The proper procedure for ?: is actually - if T and U are the same type, T - if T or U is a class type - if T converts to U and U does not convert to T, U - if U converts to T and T does not convert to U, T - otherwise error - if T and U are arithmetic or enumerations, "usual arithmetic conversions" - if T and U are pointers, "composite pointer type" There's no need for typeof anywhere, as far as I can see.

In any case this is basically what happens when BOOST_COMMON_TYPE_DONT_USE_TYPEOF and BOOST_NO_CXX11_DECLTYPE are set.

I'll take a look.

It looks to me that following the ?: specification would actually be easier to follow and more correct.

I sketched an implementation along those lines, which as a side effect defines the following useful traits: identity<T> (::type == T) remove_cv_ref<T> (remove_cv) combine_cv (copies the cv qualifiers from U to T) common_arithmetic_type (for arithmetic or enum types, their common type per "usual arithmetic conversions") composite_pointer_type ( the "composite pointer type" per the standard, that is, the pointer type to which both T and U will convert) Should we add those traits to the library proper, or is it better for them to remain implementation details? The first three seem to be rediscovered on a daily basis.

John Maddock wrote:

...

remove_cv_ref<T> (remove_cv)

I would be inclined to call that remove_cv_reference ?

remove_cv_ref is the already established name; everyone uses it. Boost has two such, one in base_from_member, another in function_types/example. remove_cv_ref: 3080 results in Google, remove_cv_reference: 6 results. Although I wouldn't be surprised if we get std::remove_cv_reference at some point, as one of those 6 results is in the LWG issue list.

...

combine_cv (copies the cv qualifiers from U to T)

See https://svn.boost.org/trac/boost/ticket/3970

copy_cv works too.

...

common_arithmetic_type (for arithmetic or enum types, their common type per "usual arithmetic conversions") composite_pointer_type ( the "composite pointer type" per the standard, that is, the pointer type to which both T and U will convert)

Should we add those traits to the library proper, or is it better for them to remain implementation details? The first three seem to be rediscovered on a daily basis.

IMO +1 on the first three, much less sure about the last 2.

The last two appear worthy because (a) they implement things that are specified in the standard; both "usual arithmetic conversions" and "composite pointer type" are in [expr] and (b) they deserve their own tests, and it's a bit odd to test implementation details. But either way is fine with me.

Care to submit a PR?

I'm not at the PR point yet, need to clean up the implementation and check against the existing tests (which are pretty slim by the way) first.

On Thu, May 28, 2015 at 9:38 AM, Peter Dimov wrote:

...

I'm not at the PR point yet, need to clean up the implementation and check against the existing tests (which are pretty slim by the way) first.

On that note, do we want to fix type_traits/alignment_of, or have it leverage align/alignment_of? alignment_of in align is more conforming to the specification, supports T[] incomplete types, and appears to work for more cases too.

(John, check out https://github.com/boostorg/align/blob/master/test/alignment_of_test.cpp, which Peter improved vastly, and try it with boost::alignment_of instead of boost::alignment::alignment_of).

If the former (fixing up type_traits/alignment_of) is the best approach, I can probably submit a PR for that. If the latter route is preferable, we could just change type_traits/alignment_of.hpp to:

#include

namespace boost { using boost::alignment::alignment_of; }

(Boost.Align doesn't depend on Boost.Type_Traits, so there are no concerns there). I would prefer to avoid introducing new dependencies if possible given

On 28/05/2015 17:54, Glen Fernandes wrote: that one aim was for the new type_traits to depend on nothing but Config. So a PR would be good, will investigate those tests too. Thanks, John.

"Let C denote the type, if any, of an unevaluated conditional expression (5.16) whose first operand is an arbitrary value of type bool, whose second operand is an xvalue of type T1, and whose third operand is an xvalue of type T2."

Ah, never mind, it passes C through the unary common_type, which does the decay. A bit odd to lose the lvalue reference in such a way though.

I sketched an implementation along those lines, ...

It's at https://github.com/pdimov/common_type Take a look and let's see how to proceed from there. I haven't yet done the member pointers, which I suspect nobody uses (they aren't covered by the existing tests), but I'll add them later for completeness. I've applied decay<> up front for simplicity, instead of faithfully doing the reference-preserving work and then throwing that away, which makes a difference in some corner cases, but I doubt that anybody will be able to tell the difference. (Needless to say, those corner cases aren't being tested at the moment.) :-) Incidentally, why is our decay<> not the same as std::decay? Should it be changed to conform?

On 28/05/2015 22:14, Peter Dimov wrote:

...

I sketched an implementation along those lines, ...

It's at

https://github.com/pdimov/common_type

Take a look and let's see how to proceed from there. I haven't yet done the member pointers, which I suspect nobody uses (they aren't covered by the existing tests), but I'll add them later for completeness.

I've applied decay<> up front for simplicity, instead of faithfully doing the reference-preserving work and then throwing that away, which makes a difference in some corner cases, but I doubt that anybody will be able to tell the difference. (Needless to say, those corner cases aren't being tested at the moment.) :-)

Incidentally, why is our decay<> not the same as std::decay? Should it be changed to conform?

Yes, I fixed that yesterday, see https://svn.boost.org/trac/boost/ticket/7760 andhttps://github.com/boostorg/type_traits/commit/d3ac8b95c4cbc8876746b573daf3f.... Does that render remove_cv_ref more or less redundant? Also noticed in your code, how easy is it to extend to other built in arithmetic types? We should support __int128 and __float128 when available for example (|BOOST_HAS_INT128, no Config macro for __float128 yet, though Math has it's own one)|. And while you're on a roll.... can you see how to fix https://svn.boost.org/trac/boost/ticket/7544? common_type should have member ::type only when such a common type exists. But this looks to be a much cleaner approach than what we have now, as well as junking those pesky dependencies. Nice work! John.

On 29/05/2015 21:18, Peter Dimov wrote:

...

And while you're on a roll.... can you see how to fix https://svn.boost.org/trac/boost/ticket/7544? common_type should have member ::type only when such a common type exists.

On C++11 or on C++03?

On C++11, it's as easy as

template struct common_type { };

template<class T> struct common_type: decay<T> { };

template

struct common_type: common_type { };

On C++03... I don't know, is there a point? It needs expression SFINAE and default template parameters for function templates and will probably not compile on most non-C++11 compilers anyway. Might be useful in principle on clang/gcc in C++03 mode, but is this an important target?

Probably not, I suspect C++11 only support is fine. The above is really neat BTW, I tried something similar in VC++ and couldn't get it to work :( John.

On 30/05/2015 00:00, Peter Dimov wrote:

John Maddock wrote:

...

Also noticed in your code, how easy is it to extend to other built in arithmetic types? We should support __int128 and __float128 when available for example (|BOOST_HAS_INT128, no Config macro for __float128 yet, though Math has it's own one)|.

https://github.com/pdimov/common_type/commit/0e27c3a82047fc4c1d71e317aeef203...

Thanks! John

On 05/26/15 23:11, Vicente J. Botet Escriba wrote:

Le 26/05/15 23:46, Aparna Kumta a écrit :

...

On 05/22/15 05:22, John Maddock wrote:

...

A heads up that the "Version2" rewrite of type traits is now in develop.

There's still lots to do - more PR's will happen over the coming weeks to remove obsoleted code from other libraries (and quash the warnings that they'd otherwise generate). The docs also need a major update.

In the mean time please do shout loudly if there are any regressions caused by this change. I am seeing several test failures for Oracle Solaris Studio runs on develop branch as follows: http://www.boost.org/development/tests/develop/developer/output/oracle-sparc...

"CC" -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -errwarn -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -I"../libs/type_traits/test/libs/tt2/light/include" -c -o "/export/home/sstrunk-tester/boost_regression/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/type_traits/test/common_type_2_test.test/sun-stlport4/release/threading-multi/common_type_2_test.o" "../libs/type_traits/test/common_type_2_test.cpp"

"../boost/type_traits/common_type.hpp", line 116: Error: detail_type_traits_common_type is not defined. "../boost/type_traits/common_type.hpp", line 116: Error: A declaration does not specify a tag or an identifier. "../boost/type_traits/common_type.hpp", line 116: Error: Use ";" to terminate declarations. "../boost/type_traits/common_type.hpp", line 116: Error: "}" expected instead of"<".

Thanks for the report. I don't see where the error could be. Do you mind to provide the result of the preprocessor on a simple example?

Modifying lines#15-#17, in boost/type_traits/common_type.hpp (shown below) causes the tests to pass. %CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -errwarn -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I.. -I../libs/type_traits/test/libs/tt2/light/include -c -o ./common_type_2_test.o ../libs/type_traits/test/common_type_2_test.cpp % % diff ./common_type.hpp common_type.hpp_orig 15,18c15,17 < #ifdef __SUNPRO_CC < # define BOOST_COMMON_TYPE_USE_TYPEOF < #endif < ---

#if defined(__SUNPRO_CC) && !defined(BOOST_COMMON_TYPE_DONT_USE_TYPEOF) # define BOOST_COMMON_TYPE_DONT_USE_TYPEOF #endif %

...

In boost/type_traits/common_type.hpp , lines #15- #17, 15 #if defined(__SUNPRO_CC) && !defined(BOOST_COMMON_TYPE_DONT_USE_TYPEOF) 16 # define BOOST_COMMON_TYPE_DONT_USE_TYPEOF 17 #endif

...

However, __typeof__ is supported and this file needs to be modified to reflect that.

We will need a patch that works for the versions of SunPro providing __typeof__. But shouldn't this be part of Boost.Typeof? Could you provide such a patch? Yes, i can submit a PR later today.

Thanks Aparna

Vicente

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