Re: [boost] [Review] Boost.Type Traits Extension ending tomorrow
On 3/19/2011 11:52 Joachim Faulhaber wrote:
(1) We can think of the triple <T,U,R> of types that plus_assign *is* applicable on. (2) Each of those operations assigned to an operator can be decomposed
Maybe the set of functions should be something like is_callable<plus, LeftOperandType, RightOperandType> result_of<plus, LeftOperandType, RightOperandType, ReturnType> retval_convertible_to<plus, LeftOperand, RightOperandType, EquivalentReturnType> Similarly, we could have is_prefix_callable<plusplus, OperandType> and is_postfix_callable<plusplus, OperandType>, which helps eliminate the ambiguity that naming-by-syntax would introduce. I favor making the operator name a template parameter because: - I suspect this will encourage a more maintainable code decomposition within the library - It will likely permit simpler extension to free functions or member functions (think is_callable<push_back, ContainerType, ValueType>) - It will likely be easier to use for higher-level libraries such as Phoenix, Proto, etc. that may pass around operator names for a while before caring about the specific operator to which they refer
Maybe the set of functions should be something like
is_callable<plus, LeftOperandType, RightOperandType>
This is interesting, however it would have to be something like: ::boost::is_callable<::boost::type_traits::operators::plus, LHS, RHS> which is then not so easy to use. Am I wrong? Frédéric
2011/3/19 Frédéric Bron <frederic.bron@m4x.org>:
Maybe the set of functions should be something like
is_callable<plus, LeftOperandType, RightOperandType>
This is interesting,
yes, I like it
however it would have to be something like: ::boost::is_callable<::boost::type_traits::operators::plus, LHS, RHS>
ideally boost::is_callable<std::plus, Left, Right> but std::op_functors seem to be restricted to singly typed functors, which I don't understand, so what about boost::is_callable<boost::op::plus, Left, Right> [boost::op::op_functors would need to be written, but that's not a problem.]
which is then not so easy to use. Am I wrong?
Hmm, where is the problem? Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
2011/3/19 Frédéric Bron <frederic.bron@m4x.org>: >> Maybe the set of functions should be something like >> >> is_callable<plus, LeftOperandType, RightOperandType> > > This is interesting,
yes, I like it
> however it would have to be something like: > ::boost::is_callable<::boost::type_traits::operators::plus, LHS, RHS>
ideally
boost::is_callable<std::plus, Left, Right>
but std::op_functors seem to be restricted to singly typed functors, which I don't understand,
I don't see op_functors in the standard. What do you mean by "restricted to singly typed functors"? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Re-Review-Boost-Type-Traits-Extension-end... Sent from the Boost - Dev mailing list archive at Nabble.com.
2011/3/20 Vicente Botet <vicente.botet@wanadoo.fr>:
Joachim Faulhaber wrote:
2011/3/19 Frédéric Bron <frederic.bron@m4x.org>:
Maybe the set of functions should be something like
is_callable<plus, LeftOperandType, RightOperandType>
This is interesting,
yes, I like it
however it would have to be something like: ::boost::is_callable<::boost::type_traits::operators::plus, LHS, RHS>
ideally
boost::is_callable<std::plus, Left, Right>
but std::op_functors seem to be restricted to singly typed functors, which I don't understand,
I don't see op_functors in the standard.
What I mean by "op_functors" are function objects that wrap operators. 20.8 Function objects [1] e.g. // 20.8.4, arithmetic operations: template <class T> struct plus;
What do you mean by "restricted to singly typed functors"?
And they are template structs parameterized with a single type T instead of e.g. template <class T, class U=T, class R=T> struct plus; all three types: Lhs argument type T, rhs argument type U and result type R. Best, Joachim [1] Document n3242=11-0012, Working Draft, Standard for Programming Language C++ -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
2011/3/20 Vicente Botet <vicente.botet@wanadoo.fr>: > > Joachim Faulhaber wrote: >> >> 2011/3/19 Frédéric Bron <frederic.bron@m4x.org>: >> >> Maybe the set of functions should be something like >> >> >> >> is_callable<plus, LeftOperandType, RightOperandType> >> > >> > This is interesting, >> >> yes, I like it >> >> > however it would have to be something like: >> > ::boost::is_callable<::boost::type_traits::operators::plus, LHS, >> RHS> >> >> ideally >> >> boost::is_callable<std::plus, Left, Right> >> >> but std::op_functors seem to be restricted to singly typed functors, >> which I don't understand, >> > > I don't see op_functors in the standard.
What I mean by "op_functors" are function objects that wrap operators.
20.8 Function objects [1]
e.g. // 20.8.4, arithmetic operations: template <class T> struct plus;
> What do you mean by "restricted to > singly typed functors"?
And they are template structs parameterized with a single type T instead of e.g.
template <class T, class U=T, class R=T> struct plus;
all three types: Lhs argument type T, rhs argument type U and result type R.
Oh, I see. This extension seems to be not disruptive. Maybe someone could make a proposal for TR2. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Re-Review-Boost-Type-Traits-Extension-end... Sent from the Boost - Dev mailing list archive at Nabble.com.
2011/3/20 Vicente Botet <vicente.botet@wanadoo.fr>:
Joachim Faulhaber wrote:
2011/3/20 Vicente Botet <vicente.botet@wanadoo.fr>:
Joachim Faulhaber wrote:
2011/3/19 Frédéric Bron <frederic.bron@m4x.org>:
Maybe the set of functions should be something like
is_callable<plus, LeftOperandType,
RightOperandType>
This is interesting,
yes, I like it
however it would have to be something like:
::boost::is_callable<::boost::type_traits::operators::plus, LHS, RHS>
ideally
boost::is_callable<std::plus, Left, Right>
but std::op_functors seem to be restricted to singly typed functors, which I don't understand,
I don't see op_functors in the standard.
What I mean by "op_functors" are function objects that wrap operators.
20.8 Function objects [1]
e.g. // 20.8.4, arithmetic operations: template <class T> struct plus;
What do you mean by "restricted to singly typed functors"?
And they are template structs parameterized with a single type T instead of e.g.
template <class T, class U=T, class R=T> struct plus;
all three types: Lhs argument type T, rhs argument type U and result type R.
Hi Vicente, there is something nasty about your mail/news reader or the combination of yours and mine. All the less '<' and greater '>' signs (and other special characters) are coming in their html encoding '>' and '<' when they return in your answers. Which is a bit unpleasant. Either the text is unreadable or I have to substitute all of them manually. I use google mail for reading boost list and I have chosen the plain text option, but maybe everyone is using html-encoding now. The phenomenon seems to occur only with *your* replies, but I don't know how others receive the text. As for function objects
20.8 Function objects [1]
e.g. // 20.8.4, arithmetic operations: template <class T> struct plus;
These are part of the old standard as well and their implementation can be found in header <functional>. They are appearing in the new standard unaltered, except for an extension for 3 bitwise operations. // 20.8.7, bitwise operations: template <class T> struct bit_and; template <class T> struct bit_or; template <class T> struct bit_xor; (that should be renamed to bitwise_xxx IMO in order to be more consistent with boost::proto naming.) I see these kinds of functors being used and useful in many contexts and specifically in boost libraries. Also they seem to be reinvented from time to time. They should really be available in their more general form, that is capable of covering all the possible overloads that are possible for the underlying operators. e.g.
template <class T, class U=T, class R=T> struct plus;
but maybe there are specific reasons that forbid such a generalization. I think there shouldn't be any since the more general form contains the old specification as a special case.
Oh, I see.
This extension seems to be not disruptive. Maybe someone could make a proposal
What has to be done for that? Best, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
participants (4)
-
Brent Spillner -
Frédéric Bron -
Joachim Faulhaber -
Vicente Botet