[Boost-users] [type traits] Extension to operator detection -> choose your preferred naming

[Frédéric Bron]

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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Patrick Horgan]

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

[Diederick C. Niehorster]

2011/8/24 Frédéric Bron <freder...@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

[Thomas Klimpel]

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

[John Maddock]

>> 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.

[Dave Abrahams]

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

[alfC]

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.

[Frédéric Bron]

> 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.

[alfC]

> 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

[Frédéric Bron]

>> 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.