[type traits] Extension to operator detection -> choose your preferred naming
It is time to include the type trait extension to the official boost trunk. These traits can detect if you can use a given operator with given arguments. For example: has_plus<double, int>::value is true because the following program compiles without error: double lhs; int rhs; lhs+rhs; We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators. Please give your preference between A, B and C before Sept. 5th. Regards, Frédéric
On 08/23/2011 11:22 PM, Frédéric Bron wrote:
...elision by patrick... We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators.
Please give your preference between A, B and C before Sept. 5th. C
Patrick
2011/8/24 Frédéric Bron <frederic.bron@m4x.org>:
We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators.
Please give your preference between A, B and C before Sept. 5th.
C, except I'd prefer has_unary_minus instead of has_negate Best, Dee
We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators.
Please give your preference between A, B and C before Sept. 5th.
C, except I'd prefer has_unary_minus instead of has_negate
LOL, well I prefer B except for has_negate where I go with C. John.
Frédéric Bron wrote:
We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNa mes I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators.
Please give your preference between A, B and C before Sept. 5th.
C Regards, Thomas
on Tue Aug 23 2011, Frédéric Bron <frederic.bron-AT-m4x.org> wrote:
It is time to include the type trait extension to the official boost trunk. These traits can detect if you can use a given operator with given arguments.
For example: has_plus<double, int>::value is true because the following program compiles without error: double lhs; int rhs; lhs+rhs;
This checks for the ability to add lvalues. Is there a way to check for rvalues? Just curious.
We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators.
Please give your preference between A, B and C before Sept. 5th.
C -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tuesday, August 23, 2011 11:22:45 PM UTC-7, Frédéric Bron wrote:
It is time to include the type trait extension to the official boost trunk. These traits can detect if you can use a given operator with given arguments.
For example: has_plus<double, int>::value is true because the following program compiles without error: double lhs; int rhs; lhs+rhs;
I just want to make the connection with the thread I opened last week: "[math][tools][units] generic libraries not generic enough" The point I want to make is that if there were a uniform facility to deduce the result of a built-in operator over some arithmetic types then library authors could do a better job at writting generic libraries on some exotic arithmetic types and combinations, for example multiply_typeof_helper<double, int>::type --> double the name is of course borrowed from boost.Units were it is intesively used: boost::unit::multiplies_typeof_helper<quantity<si::length>, quantity<si::length> >::type --> quantity<si::area> I just wanted to make the connection between the two problems; and hopeful solve the has_operator and typeof_operator problem together. Alfredo PS: what if to types can not be multiplied, etc, the has_multiplies will tell or multiplies_typeof_helper can return void, or boost::none. We have come to three proposed lists of names (A, B and C):
https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators.
Please give your preference between A, B and C before Sept. 5th.
Regards,
Frédéric _______________________________________________ Boost-users mailing list Boost...@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I just want to make the connection with the thread I opened last week: "[math][tools][units] generic libraries not generic enough"
The point I want to make is that if there were a uniform facility to deduce the result of a built-in operator over some arithmetic types then library authors could do a better job at writting generic libraries on some exotic arithmetic types and combinations, for example
multiply_typeof_helper<double, int>::type --> double
I just wanted to make the connection between the two problems; and hopeful solve the has_operator and typeof_operator problem together.
The operator traits can detect if the operator return value can be converted to a given type but not the precise return type.
PS: what if to types can not be multiplied, etc, the has_multiplies will tell or multiplies_typeof_helper can return void, or boost::none.
has_operator_multiplies<A, B>::value is false. Frédéric
The point I want to make is that if there were a uniform facility to deduce
the result of a built-in operator over some arithmetic types then library authors could do a better job at writting generic libraries on some exotic arithmetic types and combinations, for example
multiply_typeof_helper<double, int>::type --> double
I just wanted to make the connection between the two problems; and hopeful solve the has_operator and typeof_operator problem together.
The operator traits can detect if the operator return value can be converted to a given type but not the precise return type.
what do you mean by "it can't"? is that a limitation of the language? or the library? can't the built-in type cases by hard coded, e.g. template<> multiply_typeof_helper<double, int>{ typedef double type; }; it can always be specialized, and for decltype compilers it can be by default: template<class T1, class T2> multiply_typeof_helper{ typedef decltype(T1()*T2()) type; }; isn't this something that fits in type traits? Alfredo
The operator traits can detect if the operator return value can be converted to a given type but not the precise return type.
what do you mean by "it can't"? is that a limitation of the language? or the library?
library. I leave this for anybody who wants to propose an extension. As for myself, I will be happy to go to the end of my initial proposal. Frédéric
participants (7)
-
alfC -
Dave Abrahams -
Diederick C. Niehorster -
Frédéric Bron -
John Maddock -
Patrick Horgan -
Thomas Klimpel