[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
B 2011/8/24 Frédéric Bron <frederic.bron@m4x.org>:
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
B Tony
2011/8/24 Frédéric Bron <frederic.bron@m4x.org>
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.
B - Rob.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Frédéric Bron Sent: Wednesday, August 24, 2011 7:23 AM To: boost@lists.boost.org; boost-users Subject: [boost] [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.
C --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Wed, Aug 24, 2011 at 01:46:32AM -0700, Patrick Horgan wrote:
I prefer C
I never thought I'd see a statement like that on this list :D My vote is for alternative #C. -- Lars Viklund | zao@acc.umu.se
on Wed Aug 24 2011, "Paul A. Bristow" <pbristow-AT-hetp.u-net.com> wrote:
boost-bounces@lists.boost.org wrote:
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;
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
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
Frédéric Bron wrote:
Please give your preference between A, B and C before Sept. 5th.
C Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-Extension-to-operator-detecti... Sent from the Boost - Dev mailing list archive at Nabble.com.
2011/8/23 Frédéric Bron <frederic.bron@m4x.org>
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.
[...]
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.
B, followed closely by C. I also prefer s/left_shift/shift_left/ and s/right_shift/shift_right/, as it is for Proto, but I'm sure you've already considered that. At this point, I think you've taken enough input that anything you decide upon is justifiable :) - Jeff
Jeffrey Lee Hellrung, Jr. Wrote:
B, followed closely by C.
+1
I also prefer s/left_shift/shift_left/ and s/right_shift/shift_right/, as it is for Proto, but I'm sure you've already considered that.
+1
At this point, I think you've taken enough input that anything you decide upon is justifiable :)
+1 :-) Thanks, Frédéric. Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards
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
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/Opera torTraitNames
Please give your preference between A, B and C before Sept. 5th.
I'll likely be alone, but A is my preference. I'd be happy with s/can_call/has/ to shorten the names. I wonder if A is disadvantaged by that difference. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Hi Frédéric, thank you for bringing this long lasting issue to a final decision ... 2011/8/24 Frédéric Bron <frederic.bron@m4x.org>:
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.
I vote for C Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
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
participants (15)
-
alfC -
Dave Abrahams -
Frédéric Bron -
Gottlob Frege -
Jeffrey Lee Hellrung, Jr. -
Joachim Faulhaber -
John Maddock -
Lars Viklund -
Patrick Horgan -
Paul A. Bristow -
Robert Jones -
Stewart, Robert -
Sylvester-Bradley, Gareth -
Thomas Klimpel -
Vicente Botet