result_ofOp, operator should be a template parameter
An example that I think demonstrates the superiority of this: binary_operation<A,Op,B>::result_type result; over this: result_of_plus<A, B>::type result; in this directory: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/source/ array_calcs.hpp and array_calcs.cpp. The example shows an expression template for arrays based on the examples in: http://osl.iu.edu/~tveldhui/papers/techniques/ (BTW this is part of my next distro so no guarantee it works in pqs-1-01-04 , though should be ok.) Specifically making the operator a template parameter makes it generic IMHO and much reduces the work required. If an expression is required in "typeof" then it cant work generically , unless operators are allowed as template params And a generic "placeholder"operator param is included. (Simple promotion is inadequate for udts) Simple useage of binary_operation described here: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/binary_operation.... regards Andy Little
On Jul 3, 2004, at 4:38 AM, Andy Little wrote:
An example that I think demonstrates the superiority of this:
binary_operation<A,Op,B>::result_type result;
over this:
result_of_plus<A, B>::type result;
in this directory:
In Boost CVS there is an implementation of result_of, which would be used like this: result_of<Op(A, B)>::type Doug
"Doug Gregor" <dgregor@cs.indiana.edu> wrote
In Boost CVS there is an implementation of result_of, which would be used like this:
result_of<Op(A, B)>::type
I have seen this, but BTW I cant find the utilities/detail/result_of_iterate.hpp header in the boost CVS Of course there is no problem to do this and am all in favour of result_of and binary_operation is designed to work with it 'out of the box' result_of<binary_operation<A,Op,B> >::type; This is a lot easier and less work to implement than the alternatives result_of<plus(A,B) >::type // requires impl result_of<minus(A,B) >::type // etc result_of<less(A,B) >::type etc...ad infinitum outlined in the proposal, which as I understand it requires a templated nested class for each currently result_of is a a general purpose tool. My point is that when dealing with 'operators' as opposed to functions in general it is much more convenient to have one one class representing the operation than a plethora of result_of_xxx classes. Take a look in Lambda, Ublas etc etc... currently they all do their own thing on operators One common interface class (ie binary_operation) for operators would sure help when designing matrix operators etc. To do that you need a template parameter capable of representing the generic operation. regards Andy Little
On Jul 3, 2004, at 6:47 PM, Andy Little wrote:
I have seen this, but BTW I cant find the utilities/detail/result_of_iterate.hpp header in the boost CVS
??? It's there (and the regression tests are finding it). Are you using "cvs update -d"?
result_of is a a general purpose tool. My point is that when dealing with 'operators' as opposed to functions in general it is much more convenient to have one one class representing the operation than a plethora of result_of_xxx classes. Take a look in Lambda, Ublas etc etc... currently they all do their own thing on operators
If we had "smarter" versions of std::plus, std::minus, etc. that played well with result_of, I think that would solve the issue reasonably well.
One common interface class (ie binary_operation) for operators would sure help when designing matrix operators etc. To do that you need a template parameter capable of representing the generic operation.
... which is just a function object. Something like this: struct minus { template<typename> struct result; template<typename F, typename T, typename U> struct result<F(T, U)> { typedef *magic* type; }; template<typename T, typename U> typename result<minus(T, U)>::type operator()(T t, U u) { return t+u; } } Doug
"Doug Gregor" <dgregor@cs.indiana.edu> wrote
On Jul 3, 2004, at 6:47 PM, Andy Little wrote:
I have seen this, but BTW I cant find the utilities/detail/result_of_iterate.hpp header in the boost CVS
??? It's there (and the regression tests are finding it). Are you using "cvs update -d"?
nope... IE explorer ie "the web browser cvs interface". All I'm seeing is an empty directory. I better rtm.
If we had "smarter" versions of std::plus, std::minus, etc. that played well with result_of, I think that would solve the issue reasonably well.
Are there moves in this direction?
... which is just a function object. Something like this:
struct minus ;
abracadabra...??? (*magic*).... struct minus { template<typename> struct result; template<typename F, typename T, typename U> struct result<F(T, U)> {//*** assuming this is not "automagic"??? ie require user specialization... typedef typename binary_operation<T,std::minus,U>::result_type type; };//*** template<typename T, typename U> typename result<minus(T, U)>::type operator()(T t, U u) { return t-u; } } ^^^ magic1 operator +(MyUDT<Ta> a, MyUDT<Tb> b); magic 2 operator -(MyUDT<Ta> a, MyUDT<Tb> b); etc operator * (MyUDT<Ta> a, MyUDT<Tb> b); etc operator / (MyUDT<Ta> a, MyUDT<Tb> b); template<typename Ta,template < typename> class Op, typename Tb> struct binary_operation< MyUDT<Ta>, Op, MyUDT<Tb> > { typedef MyUDT<typename binary_operation<Ta,Op,Tb>::result_type > result_type; }; How does the alternative to the above look? regards Andy Little
"Doug Gregor" <dgregor@cs.indiana.edu> wrote Ok I'm onto this and agree it looks rather cool.... template<typename T> struct MyUDT; template<typename Op,typename Ta, typename Tb> struct result_of<Op(MyUDT<Ta>,MyUDT<Tb>) >{ typedef MyUDT< typename result_of<Op(Ta,Tb)>::type > type; }; int main() { result_of< minus(int,double) >::type x; } --------
If we had "smarter" versions of std::plus, std::minus, etc. that played well with result_of, I think that would solve the issue reasonably well.
This is the remaining problem. If there are to be these plus, minus functors where are they to reside or will they be the old favourites? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"Doug Gregor" <dgregor@cs.indiana.edu> wrote
If we had "smarter" versions of std::plus, std::minus, etc. that played well with result_of, I think that would solve the issue reasonably well.
This is the remaining problem. If there are to be these plus, minus functors where are they to reside or will they be the old favourites?
FWIW I'd go for something like this: result_of<operator_plus(int,int)>::type z = operator_plus()(x,y); result_of<operator_minus(int,int)>::type z = operator_minus()(x,y); result_of<operator_multiplies(int,int)>::type z = operator_multiplies()(x,y); regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:cc8gss$7c8$1@sea.gmane.org...
result_of<operator_plus(int,int)>::type z = operator_plus()(x,y); result_of<operator_minus(int,int)>::type z = operator_minus()(x,y); result_of<operator_multiplies(int,int)>::type z = operator_multiplies()(x,y);
One problem with this scheme is getting traits information out of it. For instance the original std::plus has std::plus<T>::first_argument_type. If operator_plus is a plain class, operator_plus(A,B) is in fact just three encoded parameters so always has to be wrapped in something if passed as one parameter, (Please correct me if I'm wrong, I'm not too up on function object template params), whereas operator_plus<A,B> works as one parameter and as a traits class. result_of<operator_plus<A,B> >::type seems to be a lot simpler to deal with in this respect than result_of<operator_plus(A,B) >:: type Apologies for sending 4 posts in a row. I would like to use 'official methods' if possible, but this whole area is quite important to my physical-quantities project. regards Andy Little
Doug Gregor wrote:
On Jul 3, 2004, at 4:38 AM, Andy Little wrote:
An example that I think demonstrates the superiority of this:
binary_operation<A,Op,B>::result_type result;
over this:
result_of_plus<A, B>::type result;
in this directory:
In Boost CVS there is an implementation of result_of, which would be used like this:
result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman <joel@boost-consulting.com> writes:
Doug Gregor wrote:
On Jul 3, 2004, at 4:38 AM, Andy Little wrote:
An example that I think demonstrates the superiority of this:
binary_operation<A,Op,B>::result_type result;
over this:
result_of_plus<A, B>::type result;
in this directory: In Boost CVS there is an implementation of result_of, which would be used like this: result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time.
...which is just a temporary solution while we wait for decltype? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Jul 5, 2004, at 3:00 PM, David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Doug Gregor wrote:
On Jul 3, 2004, at 4:38 AM, Andy Little wrote:
An example that I think demonstrates the superiority of this:
binary_operation<A,Op,B>::result_type result;
over this:
result_of_plus<A, B>::type result;
in this directory: In Boost CVS there is an implementation of result_of, which would be used like this: result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time.
...which is just a temporary solution while we wait for decltype?
Absolutely. But it's a solution we can use to make C++98/C++0x portable libraries. At least, that's the idea :) Doug
Doug Gregor <dgregor@cs.indiana.edu> writes:
On Jul 5, 2004, at 3:00 PM, David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Doug Gregor wrote:
On Jul 3, 2004, at 4:38 AM, Andy Little wrote:
An example that I think demonstrates the superiority of this:
binary_operation<A,Op,B>::result_type result;
over this:
result_of_plus<A, B>::type result;
in this directory: In Boost CVS there is an implementation of result_of, which would be used like this: result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time.
...which is just a temporary solution while we wait for decltype?
Absolutely. But it's a solution we can use to make C++98/C++0x portable libraries. At least, that's the idea :)
Why don't we implement it for compilers that support some kind of typeof, and then get Arkadiy Vertlyjb's (sp?) typeof library going? Then we can slap a more-portable interface on it and start using it all over Boost ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Jul 5, 2004, at 6:43 PM, David Abrahams wrote:
Doug Gregor <dgregor@cs.indiana.edu> writes:
Absolutely. But it's a solution we can use to make C++98/C++0x portable libraries. At least, that's the idea :)
Why don't we implement it for compilers that support some kind of typeof, and then get Arkadiy Vertlyjb's (sp?) typeof library going?
If only I could remember what compilers supported it :) I know newer versions of GCC do.
Then we can slap a more-portable interface on it and start using it all over Boost ;-)
Something like result_of_N<F, T1, T2, ..., TN>, I'd expect. Is Arkadiy's typeof lib going in some time soon? Doug
"Doug Gregor" <dgregor@cs.indiana.edu> wrote
On Jul 5, 2004, at 3:00 PM, David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
in this directory: In Boost CVS there is an implementation of result_of, which would be used like this: result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time.
...which is just a temporary solution while we wait for decltype?
Absolutely. But it's a solution we can use to make C++98/C++0x portable libraries. At least, that's the idea
The key issue for me is not result_of which I am happy with, but rather the resolution of the Op param above to one common function-object (or set of function-objects)representing plus, minus etc in context of operators. std::plus and the others in <functional> are the predecessors for what I'm talkng about but I think are past their best. IOW one common interface * for result_type of operators ++ * that all UDTs and fundamental types can implement. This would for example ease use of UDTs as value_types in my physical-quantities library.I have had some success for example with boost::inteval etc, but this has required me writing some result_of style functors in My style rather than implementing one common functionality. As another example it would allow use of my physical-quantities type to be used in arrays and matrices etcetera, without me having to rewrite interfaces in the style of That particular library. FWIW Here is my take on it. result_of<operator_plus(A,B)>::type // ok pretty interface , but harder to write traits for. ie first_argument_type for compat with predecessors first_argument<operator_plus(A,B)>::type //? (Other useful traits for operator... precedence, associativity, commutative, const char*const symbol (return "+";} etc) So I am happy with that as one user interface, but then a layer further down such as binary_operation which is wrapped by the interface. I have currently implemented it thus: template<template <typename> class Op> struct operator_{ // just a base class for operator_XX functors template<typename> struct result; //for result_of template<typename F, typename T, typename U> struct result<F(T,U)> { typedef typename binary_operator< T, Op, U >::result_type type; }; // further members eg.. operator()(...)'s and possibly static apply(...)'s }; struct operator_minus : operator_<std::minus>{}; struct operator_plus : operator_<std::plus>{}; struct operator_multiplies : operator_<std::multiplies>{}; struct operator_divides : operator_<std::divides>{}; struct operator_shift_left : operator_<shift_left>{}; etc Rationale Specialising at the level of operator_plus etc above I have tried. It works ok in (win) VC7.1 but (djgpp) gcc3.2 chokes on it. (That is the extent of my technology I'm afraid) // tried like so... template<> struct operator_plus::template result<operator_plus(A,B)>{ //<< gcc chokes here }; However by also providing the binary_operation layer specialisation can also be achieved via an alternative route. I also happen to like binary_operation because it represents the set {binary_operations} rather than bits and pieces which works better for me at a 'generic' level. regards Andy Little
"David Abrahams" <dave@boost-consulting.com> wrote
Joel de Guzman <joel@boost-consulting.com> writes:
Doug Gregor wrote:
result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time.
...which is just a temporary solution while we wait for decltype?
Apologies, its not clear from the subject. I am referring to operations, which have more attributes than just the type of the result. For example a multiplication maybe commutative in one context, but not in another. This sort of information could be used by an optimizer walking about in an expression template for example. stream output of the symbol for the particular operator provides a simple way of debugging in generic code. A "super-functional" functor with specialisable traits would provide a common mechanism for specializing operations for UDT's. IOW A way for the UDT designer to communicate their intent to users of operations on their types and how they interact with other types. At the simplest level for example, communicating whether an operation between two types from different libraries is supported. So there is more to it than just decltype. I am talking about operations rather than types after all. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
Joel de Guzman <joel@boost-consulting.com> writes:
Doug Gregor wrote:
result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time.
...which is just a temporary solution while we wait for decltype?
Apologies, its not clear from the subject. I am referring to operations, which have more attributes than just the type of the result. For example a multiplication maybe commutative in one context, but not in another.
What constitutes context other than the argument types involved?
This sort of information could be used by an optimizer walking about in an expression template for example.
I think most of us are very well aware of uses for result type detection.
stream output of the symbol for the particular operator provides a simple way of debugging in generic code. A "super-functional" functor with specialisable traits would provide a common mechanism for specializing operations for UDT's.
That part is all incomprehensible to me.
IOW A way for the UDT designer to communicate their intent to users of operations on their types and how they interact with other types. At the simplest level for example, communicating whether an operation between two types from different libraries is supported.
Provided that's the same question as "is there an overload that will match these arguments", we already know how to detect that without any user intervention.
So there is more to it than just decltype. I am talking about operations rather than types after all.
The right thing to do is for overloads to be written to operate only on appropriate combinations of types, IMO. Then you don't need a "super-functional functor" or whatever. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
For example a multiplication maybe commutative in one context, but not in another.
What constitutes context other than the argument types involved?
* is not a context ,{ a * b} is a context. What more do you need? What more have I implied?
This sort of information could be used by an optimizer walking about in an expression template for example.
I think most of us are very well aware of uses for result type detection.
stream output of the symbol for the particular operator provides a
simple
way of debugging in generic code. A "super-functional" functor with specialisable traits would provide a common mechanism for specializing operations for UDT's.
That part is all incomprehensible to me.
I found output of (say) operator + as "+" useful in following the execution of expression templates. "super-functional" is an off-the-cuff replacement for <functional>. Dont take it too seriously, but std::plus etc are past their best. If I wish to know whether an operation on two types is commutative, I might like to be able to quiz the operation about it. decltype wont do that for me.
IOW A way for the UDT designer to communicate their intent to users of operations on their types and how they interact with other types. At the simplest level for example, communicating whether an operation between two types from different libraries is supported.
Provided that's the same question as "is there an overload that will match these arguments", we already know how to detect that without any user intervention.
The compiler does. We dont... we're long gone. ConceptChecking helps the user interface part.
So there is more to it than just decltype. I am talking about operations rather than types after all.
The right thing to do is for overloads to be written to operate only on appropriate combinations of types, IMO. Then you don't need a "super-functional functor" or whatever.
I need some way to get information about the result types of my value_types operation. eg What results form mux of a interval<double> and a double. result_of is ok as far as it goes. but 1) There needs to be a common name for Op ie operator_XX or whatever. Otherwise we will all be carrying on our merry own way. That is the status quo. 2) In theory result_of is specializable for functors. It would be useful to test to find out how well this works in practise. Results on gcc3.2 have not been encouraging. 3) typeof, decltype etc is not standard C++ as it stands. Its a non-starter. Therefore if I understand it correctly your advice to me is to wait for decltype to be in the standard? OTOH point me at the specs answering the above. -------- What is The new version of MTLs take on UDT value_types. Or is it to be any colour you like as long as its double? To be generic it should of course support my physical-quantities type... with one common interface . ;-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
For example a multiplication maybe commutative in one context, but not in another.
What constitutes context other than the argument types involved? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* is not a context ,{ a * b} is a context. What more do you need? What more have I implied?
You say you're talking about "operations not types", but I think you're just mystifying something that's simple. Whether or not multiplication is commutative depends entirely on the types of its operands.
I found output of (say) operator + as "+" useful in following the execution of expression templates. "super-functional" is an off-the-cuff replacement for <functional>. Dont take it too seriously, but std::plus etc are past their best. If I wish to know whether an operation on two types is commutative, I might like to be able to quiz the operation about it. decltype wont do that for me.
And neither should that trait be glommed into the one used for determining result types.
IOW A way for the UDT designer to communicate their intent to users of operations on their types and how they interact with other types. At the simplest level for example, communicating whether an operation between two types from different libraries is supported.
Provided that's the same question as "is there an overload that will match these arguments", we already know how to detect that without any user intervention.
The compiler does. We dont...
Depending on who "we" is, yes we do. At least I do. Ask Greg Colvin for my is_modable implementation.
we're long gone. ConceptChecking helps the user interface part.
The right thing to do is for overloads to be written to operate only on appropriate combinations of types, IMO. Then you don't need a "super-functional functor" or whatever.
I need some way to get information about the result types of my value_types operation. eg What results form mux of a interval<double> and a double.
result_of is ok as far as it goes. but 1) There needs to be a common name for Op ie operator_XX or whatever.
Sure.
Otherwise we will all be carrying on our merry own way. That is the status quo.
2) In theory result_of is specializable for functors.
It's a fact.
It would be useful to test to find out how well this works in practise. Results on gcc3.2 have not been encouraging.
Maybe a compiler bug?
3) typeof, decltype etc is not standard C++ as it stands. Its a non-starter.
Not neccessarily. We can build a pretty nice typeof replacement that requires just a little help from users.
Therefore if I understand it correctly your advice to me is to wait for decltype to be in the standard? OTOH point me at the specs answering the above.
Nope, I wasn't giving you any advice. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uk6xhf6kh.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
You say you're talking about "operations not types", but I think
hmmm.. Actual quote is " I am talking about operations rather than types after all."
you're just mystifying something that's simple. Whether or not multiplication is commutative depends entirely on the types of its operands.
Whether or not a binary operation is commutative depends on the operator and the types and values of its operands. int x=10,y=x; assert(y/x == x/y);assert(y-x == x-y);
I found output of (say) operator + as "+" useful in following the execution of expression templates. "super-functional" is an off-the-cuff replacement for <functional>. Dont take it too seriously, but std::plus etc are past their best. If I wish to know whether an operation on two types is commutative, I might like to be able to quiz the operation about it. decltype wont do that for me.
And neither should that trait be glommed into the one used for determining result types.
Keep talking... youre winning me over... Though I shall mourn glomming.. for it is a less practised art... [snip]
I need some way to get information about the result types of my value_types operation. eg What results form mux of a interval<double> and a double.
result_of is ok as far as it goes. but 1) There needs to be a common name for Op ie operator_XX or whatever.
Sure.
I suggest operator_plus etc ( cos it's close to operator+)... maybe there are other candidates...?
Otherwise we will all be carrying on our merry own way. That is the status quo.
2) In theory result_of is specializable for functors.
It's a fact.
It would be useful to test to find out how well this works in practise. Results on gcc3.2 have not been encouraging.
Maybe a compiler bug?
...but maybe not in gcc.
3) typeof, decltype etc is not standard C++ as it stands. Its a non-starter.
Not neccessarily. We can build a pretty nice typeof replacement that requires just a little help from users.
Any documentation of this you can point me to ....? I hope "a little help from users " means what it says. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uk6xhf6kh.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
You say you're talking about "operations not types", but I think
hmmm.. Actual quote is " I am talking about operations rather than types after all."
Did my (mis)quoting differ in substance, or can we forget it?
you're just mystifying something that's simple. Whether or not multiplication is commutative depends entirely on the types of its operands.
Whether or not a binary operation is commutative depends on the operator and the types and values of its operands.
int x=10,y=x; assert(y/x == x/y);assert(y-x == x-y);
Sure.
I found output of (say) operator + as "+" useful in following the execution of expression templates. "super-functional" is an off-the-cuff replacement for <functional>. Dont take it too seriously, but std::plus etc are past their best. If I wish to know whether an operation on two types is commutative, I might like to be able to quiz the operation about it. decltype wont do that for me.
And neither should that trait be glommed into the one used for determining result types.
Keep talking... youre winning me over... Though I shall mourn glomming.. for it is a less practised art...
Whatever that means. I'm not sure it's an art, and I'm not convinced it's less-practiced than separation-of-concerns, which is what I'm advocating. I see glomming ("Blob-ing", really) all over.
3) typeof, decltype etc is not standard C++ as it stands. Its a non-starter.
Not neccessarily. We can build a pretty nice typeof replacement that requires just a little help from users.
Any documentation of this you can point me to ....? I hope "a little help from users " means what it says.
It means registering user-defined types and templates that may participate in the result type. Arkadiy's typeof from the Boost Files area at yahoogroups: http://tinyurl.com/32mlf No docs, lots of examples. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Any documentation of this you can point me to ....? I hope "a little help from users " means what it says.
It means registering user-defined types and templates that may participate in the result type.
Arkadiy's typeof from the Boost Files area at yahoogroups: http://tinyurl.com/32mlf
No docs, lots of examples.
Thanks... I'll take a look. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote David Abrahams wrote
Arkadiy's typeof from the Boost Files area at yahoogroups: http://tinyurl.com/32mlf
(BTW tinyurl died when I tried it direct... look for typeof.zip on boost yahoo files)
No docs, lots of examples.
It has some docs , which are entirely adequate to get you going IMO.
Thanks... I'll take a look.
Well . I've tested it and am pleased to report that it works well .. test code at the end. In relation to my physical_quantities library when you want a temporary, by the time you've registered it it may simpler to use the result_of approach, where there is no requirement to register. But that is a problem particular to my library where new types of unknown origin are being computed all the time in a calculation. IOW you need result_of to compute typeof as in code below. Whatever... it does the job well. .. worth a look. regards Andy Little ------------------------------------ #include <boost/typeof/typeof.hpp> #include "pqs/pqs.hpp" //Note: not available in pqs-1-01-04 #include "pqs/operators/binary_operator_functors.hpp" #define BOOST_TYPEOF_REGISTRATION_GROUP \ BOOST_TYPEOF_USER_GROUP +1 BOOST_TYPEOF_REGISTER_TYPE(pqs::q_length::m); BOOST_TYPEOF_REGISTER_TYPE(pqs::q_time::s); // required because a temporary result of calc // is not same signature as q_velocity::m_div_s in pqs-2-00-01 typedef boost::result_of< pqs::operator_divides(pqs::q_length::m, pqs::q_time::s)
::type anonymous_velocity; BOOST_TYPEOF_REGISTER_TYPE(anonymous_velocity);
#undef BOOST_TYPEOF_REGISTRATION_GROUP using namespace pqs; // dummy function return test BOOST_TYPEOF(q_length::m()/q_time::s()) my_func1() { return q_length::m(1) / q_time::s(1); } int main() { q_length::m m(1); q_time::s t(1); BOOST_AUTO(v, m/t); std::cout << v <<'\n'; BOOST_TYPEOF(m/t) f1; std::cout << f1 <<'\n'; q_velocity::m_div_s v1 = my_func1(); }
"Joel de Guzman" <joel@boost-consulting.com> wrote
Doug Gregor wrote:
In Boost CVS there is an implementation of result_of, which would be used like this:
result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time.
Apologies for the criticism. Whats more important in your type deduction header is the underlying implementation mechanism, which would of course be useful whatever interface is used. regards Andy Little
Andy Little wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote
Doug Gregor wrote:
In Boost CVS there is an implementation of result_of, which would be used like this:
result_of<Op(A, B)>::type
I think this is the best interface I've seen so far. The result_of_plus is just a temporary solution while waiting for Doug's result_of work which was not available at the time.
Apologies for the criticism. Whats more important in your type deduction header is the underlying implementation mechanism, which would of course be useful whatever interface is used.
No need to apologize. No offense taken. We share the opinion that result_of_plus is plain and utterly ugly. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Doug Gregor" <dgregor@cs.indiana.edu> wrote
On Jul 3, 2004, at 4:38 AM, Andy Little wrote:
An example that I think demonstrates the superiority of this:
binary_operation<A,Op,B>::result_type result;
over this:
result_of_plus<A, B>::type result;
in this directory:
In Boost CVS there is an implementation of result_of, which would be used like this:
result_of<Op(A, B)>::type
One issue with calling the functor Op()(a,b); compared to: binary_operation<A,Op,B>()(a,b); is that it appears to limit you to either passing arguments by value or by const reference for all arguments.(without much more specialization) Again I can't be sure this is correct but it seems to be the case . template<template < typename> class Op > struct operator_ { /* ... result type decls members */. template<typename L, typename R> typename result< operator_<Op>(L,R) >::type // Error cant deduce... operator()( typename meta::as_const_argument<L>::type l, typename meta::as_const_argument<R>::type r) //limited to one or other of the following operator()(L const& l, R const & r) operator()(L l, R r) { return binary_operator<L,Op,R>()(l,r); } }; regards Andy Little
participants (4)
-
Andy Little -
David Abrahams -
Doug Gregor -
Joel de Guzman