mpl functions, pow_, root_, reciprocal
Hi, Following preliminary ok of "pow" mpl metafunction by Alexey Gurtovoy... Here are some basic headers for mpl functions pow_, root_ and reciprocal. useage: boost::mpl::pow_<type,exponent>::type boost::mpl::root_<type,exponent>::type boost::mpl::reciprocal<type>::type Obvious type for the type and exponent is a static_rational type. For pow_ param order is same as runtime std::pow(x,y) , "root_" follows logically from pow_ .... but obviously ... pow_ could do the job) reciprocal also useful to represent 1/ type. I don't know enough mpl yet to provide generic examples except using the pqs types. If anyone else wants to have a go...? And of course docs :-) . Otherwise will get on with it asap. Feedback welcome. regards Andy Little ---------------------------------------------------------------- headers: #ifndef BOOST_MPL_POW_HPP_INCLUDED #define BOOST_MPL_POW_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type, typename Power> struct pow_ { typedef implementation_defined type }; }} //boost::mpl #endif //----------------- #ifndef BOOST_MPL_ROOT_HPP_INCLUDED #define BOOST_MPL_ROOT_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type, typename Power> struct root_ { typedef implementation_defined type; }; }} //boost::mpl #endif //----------------------------------- #ifndef BOOST_MPL_RECIPROCAL_HPP_INCLUDED #define BOOST_MPL_RECIPROCAL_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type> struct reciprocal{ typedef implementation_defined type; }; }} //boost::mpl #endif
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Hi, Following preliminary ok of "pow" mpl metafunction by Alexey Gurtovoy... Here are some basic headers for mpl functions pow_, root_ and reciprocal.
useage: boost::mpl::pow_<type,exponent>::type boost::mpl::root_<type,exponent>::type boost::mpl::reciprocal<type>::type
These aren't very interesting metafunctions, since they're all equivalent to mpl::always<implementation_defined> ;-) What is the reason for the trailing underscores?
Obvious type for the type and exponent is a static_rational type. For pow_ param order is same as runtime std::pow(x,y) , "root_" follows logically from pow_ .... but obviously ... pow_ could do the job) reciprocal also useful to represent 1/ type. I don't know enough mpl yet to provide generic examples except using the pqs types. If anyone else wants to have a go...? And of course docs :-) . Otherwise will get on with it asap.
Feedback welcome.
regards Andy Little ---------------------------------------------------------------- headers:
#ifndef BOOST_MPL_POW_HPP_INCLUDED #define BOOST_MPL_POW_HPP_INCLUDED
namespace boost { namespace mpl{
template <typename Type, typename Power> struct pow_ { typedef implementation_defined type
...
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uvfmsyz69.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Hi, Following preliminary ok of "pow" mpl metafunction by Alexey Gurtovoy... Here are some basic headers for mpl functions pow_, root_ and reciprocal.
useage: boost::mpl::pow_<type,exponent>::type boost::mpl::root_<type,exponent>::type boost::mpl::reciprocal<type>::type
These aren't very interesting metafunctions, since they're all equivalent to mpl::always<implementation_defined> ;-)
Oops sorry perhaps read 'undefined',' user defined' not implementation defined :-) Not to stay that way just havent had time to write some simple examples. (pow_<int_,int_> should be easy!) Could use one of my own but doesnt mean much to many --> The problem is I have specialised plus, minus, multiplies etc. for use in 'expression templates'. (think is right term). However it would be odd to put these in separate namespace. OTOH I could derive all from mpl in other namespace, but I didnt want to be 'ad-hoc'. ;-) But maybe that is how mpl functions should be used?. Was waiting for the book ... :-) template< typename Coherent_exponent , typename Incoherent_mux, typename Tag typename Exponent > struct pow_< pqs::q_unit< Coherent_exponent, Incoherent_mux, Tag >, Exponent >{ // incoherent and tags removed // multiply exponents typedef typename pqs::q_unit< typename multiplies< Coherent_exponent, Exponent >::type, typename Incoherent_mux::zero_type, typename Tag::default_type >::type type; };
What is the reason for the trailing underscores?
In case of pow_ to stop it name-clashing with pow(x,y), if 'using boost::mpl' ,using std. In case of root_ for similarity with pow. In case of reciprocal the underscore is very small. Thought 'power' might also clash with other names. But any suggestions appreciated. regards Andy Little
Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message
What is the reason for the trailing underscores?
In case of pow_ to stop it name-clashing with pow(x,y), if 'using boost::mpl' ,using std. In case of root_ for similarity with pow. In case of reciprocal the underscore is very small. Thought 'power' might also clash with other names. But any suggestions appreciated.
This is not the "traditional" use of trailing underscores. Normally they are used for keywords. int -> int_ bool -> bool_ etc. MPL uses tons of names that clashes with names in std. This is a problem for the user, not the library. -- Daniel Wallin
"Daniel Wallin" <dalwan01@student.umu.se> wrote in message news:401BE08C.7070604@student.umu.se...
Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message
What is the reason for the trailing underscores?
In case of pow_ to stop it name-clashing with pow(x,y), if 'using boost::mpl' ,using std. In case of root_ for similarity with pow. In case of reciprocal the underscore is very small. Thought 'power' might also clash with other names. But any suggestions appreciated.
This is not the "traditional" use of trailing underscores. Normally they are used for keywords.
int -> int_ bool -> bool_
etc. MPL uses tons of names that clashes with names in std. This is a problem for the user, not the library.
I am attempting to write a libaray for 'users'. Its my problem. Is the mpl namespace regarded as a 'user interface' ? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
This is not the "traditional" use of trailing underscores. Normally they are used for keywords.
int -> int_ bool -> bool_
etc. MPL uses tons of names that clashes with names in std. This is a problem for the user, not the library.
I am attempting to write a libaray for 'users'.
Many 'users' don't use using-declarations and won't appreciate having perfectly usable names uglified with extra underscores, or having names in mpl:: which don't follow the MPL conventions.
Its my problem. Is the mpl namespace regarded as a 'user interface' ?
If we're putting the names in mpl::, they should follow the same conventions as the rest of the library. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
These aren't very interesting metafunctions, since they're all equivalent to mpl::always<implementation_defined> ;-)
Oops sorry perhaps read 'undefined',' user defined' not implementation defined :-)
My point was to say that you are proposing we add something to the library, but you haven't shown us anything but a sketch of a few empty metafunctions. How can anyone comment?
Not to stay that way just havent had time to write some simple examples. (pow_<int_,int_> should be easy!) Could use one of my own but doesnt mean much to many -->
The problem is I have specialised plus, minus, multiplies etc. for use in 'expression templates'. (think is right term). However it would be odd to put these in separate namespace.
?? Specializations can only go in the same namespace as the primary template. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
[snip]
?? Specializations can only go in the same namespace as the primary template.
but not derived ;-). 1) Can there be some operators representing power,root and reciprocal in mpl? 2) If 1), what names can mpl connoiseurs provide? Any feedback welcome. 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:
[snip]
?? Specializations can only go in the same namespace as the primary template.
but not derived ;-).
That sentence fragment is incomprehensible to me.
1) Can there be some operators representing power,root and reciprocal in mpl?
Sounds good to me.
2) If 1), what names can mpl connoiseurs provide?
Your names seem fine to me, except for the needless trailing underscores. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ur7xfv7yt.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
These aren't very interesting metafunctions, since they're all equivalent to mpl::always<implementation_defined> ;-)
Oops sorry perhaps read 'undefined',' user defined' not implementation defined :-)
My point was to say that you are proposing we add something to the library,
Whoa ! First I decide against using mpl at all. I was accused of being 'ad-hoc'. I decide to try it. I find a problem. Next I posted a question on users about how to integrate a power function with mpl. NOTE the "Ideally" in second line !!! Here is Alexei Gurtovoys reply: " Andy Little wrote:
Hi,
Hi Andy,
I am implementing the mpl math operators for my physical_quantities type. Ideally I would like to declare a boost::mpl::power<A,B> metafunction. I would like to do:
typedef Power_type<...> P ; pq_xx a;
boost::mpl::power< pq_xx, P >::type b = run_time_power<P>( a);
OTOH: boost::mpl::power< P, pq_xx >::type b = run_time_power<P>( a); (param order ... TBD)
I am assuming it is ok to specialise plus, minus, multiplies etc in the boost::mpl namespace?
Yes, totally.
I could of course put power (or whatever name) outside the boost::mpl namespace but that is not ideal. Any thoughts?
If you contribute an implementation for it, I'd be happy to put the metafunction in the library. -- Aleksey Gurtovoy "
but you haven't shown us anything but a sketch of a few empty metafunctions. How can anyone comment?
I don't know but that doesnt seem to stop you guys! This was not a Proposol but a tentative question...what if. The next version of pqs will be available soon. The metafunctions are in!. What namespace to put these metafunctions in TBD. Meanwhile you may need to use your imagination. It should not be too hard to understand their purpose surely?. Zounds!.. I shall write some examples! may lose some accuracy on reciprocal<int_> !...unless reciprocal< int_>-->rational ... Hmm... found a boost mpl rational_c :-) ...but no docs :-(
Not to stay that way just havent had time to write some simple examples. (pow_<int_,int_> should be easy!) Could use one of my own but doesnt
mean
much to many -->
The problem is I have specialised plus, minus, multiplies etc. for use in 'expression templates'. (think is right term). However it would be odd to put these in separate namespace.
?? Specializations can only go in the same namespace as the primary template.
but not derived :-). the topic. 1) Can there be some operators representing power,root and reciprocal in mpl?. Some other math functions might also be useful... e.g to work around compile time real calc problems. 2) If 1), what names can mpl connoiseurs provide? I prefer this type of thing: boost::mpl::pow_t<my::my_type,my::my_exp >::type y; the _t suffix says it returns a type, says its a metafunction, has history and prevents nameclash with runtime. 4 for the price of 1 :-) It was of course rejected ... because "One would consider it a reprehensible abomination to use such a convention in mpl. It is simply not Done."..etc. Although no logic followed. Hmm..hm.hm ... I could do: plus_t<q_length::m,q_length::mm>::type L; divides_t<q_length::m,q_time::s>::type V; :-) Seriously though.. Perhaps that may be better because I am not using the operators to represent a compile-time operation, but the type returned as a result of the runtime operation... maybe that is an important distinction? And it would solve the problem...for me anyways:-) Alternatively reserve mpl namespace for 'operators'. boost::mpl::math ? Whatever you guys decide...meanwhile apologies for trespassing in your namespace regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ur7xfv7yt.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
These aren't very interesting metafunctions, since they're all equivalent to mpl::always<implementation_defined> ;-)
Oops sorry perhaps read 'undefined',' user defined' not implementation defined :-)
My point was to say that you are proposing we add something to the library,
Whoa !
Whoa, what? Are you not proposing we add something to the library?
First I decide against using mpl at all. I was accused of being 'ad-hoc'. I decide to try it. I find a problem. Next I posted a question on users about how to integrate a power function with mpl. NOTE the "Ideally" in second line !!! Here is Alexei Gurtovoys reply:
<snip> Whoa! I saw Aleksey's reply when he posted it. What's your point?
but you haven't shown us anything but a sketch of a few empty metafunctions. How can anyone comment?
I don't know but that doesnt seem to stop you guys!
You did end your post with: "Feedback welcome."
This was not a Proposol but a tentative question...what if.
What kinds of answers were you expecting? The only technical content in your post was the names of three metafunctions. My feedback was, basically, "you should follow MPL naming conventions, and if you want more feedback you'll need to show more details"
The next version of pqs will be available soon. The metafunctions are in!. What namespace to put these metafunctions in TBD. Meanwhile you may need to use your imagination. It should not be too hard to understand their purpose surely?.
I don't have a problem understanding their purpose.
Zounds!
Take it easy, dude.
.. I shall write some examples! may lose some accuracy on reciprocal<int_> !...unless reciprocal< int_>-->rational ... Hmm... found a boost mpl rational_c :-) ...but no docs :-(
Patches welcome.
1) Can there be some operators representing power,root and reciprocal in mpl?. Some other math functions might also be useful... e.g to work around compile time real calc problems. 2) If 1), what names can mpl connoiseurs provide? I prefer this type of thing:
boost::mpl::pow_t<my::my_type,my::my_exp >::type y;
the _t suffix says it returns a type
Another creative non-conformance with MPL naming conventions. All metafunctions return types, and we don't want to uglify them all with "_t".
, says its a metafunction, has history
What history is there behind "pow_t"?
and prevents nameclash with runtime. 4 for the price of 1 :-) It was of course rejected ... because "One would consider it a reprehensible abomination to use such a convention in mpl. It is simply not Done."..etc.
Don't be such a drama queen; what was actually said was a lot more matter-of-fact. You did ask for feedback.
Although no logic followed.
False. The logic is that we already have a naming convention in MPL. Are you proposing to change it now? Non-conformance weakens any convention.
Hmm..hm.hm ... I could do:
plus_t<q_length::m,q_length::mm>::type L; divides_t<q_length::m,q_time::s>::type V;
Apparently another conflict with MPL naming.
Seriously though.. Perhaps that may be better because I am not using the operators to represent a compile-time operation, but the type returned as a result of the runtime operation... maybe that is an important distinction? And it would solve the problem...for me anyways:-)
Alternatively reserve mpl namespace for 'operators'. boost::mpl::math ?
Whatever you guys decide...
I think the MPL conventions are fine as-is, and probably should be followed.
meanwhile apologies for trespassing in your namespace
If you want to apologize, it should be for asking for feedback and then wigging out and mischaracterizing the responses when they weren't what you expected. -- Dave Abrahams Boost Consulting 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
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
[snip]
Whoa !
Whoa, what? Are you not proposing we add something to the library?
What me guvnor? No... It was the other bloke ! [snip]
What kinds of answers were you expecting? The only technical content in your post was the names of three metafunctions. My feedback was, basically, "you should follow MPL naming conventions, and if you want more feedback you'll need to show more details".
Ok... boost::mpl::pow, boost::mpl::root, boost::mpl::reciprocal. Feedback welcome :-) [snip]
.. I shall write some examples! may lose some accuracy on reciprocal<int_> !...unless reciprocal< int_>-->rational ... Hmm... found a boost mpl rational_c :-) ...but no docs :-(
Patches welcome.
OK I have started on boost::mpl::rational_c. I have derived from that into boost::mpl::integral_rational_c. In implementing that I need some promotion...so may try Fernando Cacciolas converter. OTOH Alexey Gurtovoys types_promotion_traits if all needs to be mpl. Other promotion metafunction implementations welcome. I seem to remember one candidate for the library but dont know where to find it. I would be happy to use that if possible.
From there I go to int_rational, long_rational etc I prefer int_rat but.... ok forget it :-)
Finally can use that to implement simple pow,root reciprocal etc. Should I do reciprocal<integral_c> --> integral_rational_c or is that a user thing? [snip]
the _t suffix says it returns a type
Another creative non-conformance with MPL naming conventions. All metafunctions return types, and we don't want to uglify them all with "_t".
I like it...ok forget it :-)
, says its a metafunction, has history
What history is there behind "pow_t"?
wchar_t, etc ..ok ... forget it :-) [more on _t suffix]
Apparently another conflict with MPL naming.
Seriously though.. Perhaps that may be better because I am not using the operators to represent a compile-time operation, but the type returned as a result of the runtime operation... maybe that is an important distinction? And it would solve the problem...for me anyways:-)
I stand by the above. There are two distinct types of operations. Some are designed to return a compile time value. Some are designed to return a type. I keep 'bumping into' this issue and I dont like it ! I suspect it occurs only when you start to specialise the operators for UDTs. It gets worse, I think Phil Richards uses plus where I would use multiplies. One good reason to pull the user level stuff out of the mpl namespace to prevent confusion.
Alternatively reserve mpl namespace for 'operators'. boost::mpl::math ?
Whatever you guys decide...
I think the MPL conventions are fine as-is, and probably should be followed.
Are there some written guidelines on these conventions or am I just meant to 'know' them? hmm..I seem to remember asking this before :-)
meanwhile apologies for trespassing in your namespace
If you want to apologize, it should be for asking for feedback and then wigging out and mischaracterizing the responses when they weren't what you expected.
Apologies for the 'attitude'... I have been working 3 days straight on mplising my lib... and I'm smokin' :-) Apologies for my apology... and that one... Thanks for the feedback :-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Ok... boost::mpl::pow, boost::mpl::root, boost::mpl::reciprocal.
Feedback welcome :-)
[snip]
.. I shall write some examples! may lose some accuracy on reciprocal<int_> !...unless reciprocal< int_>-->rational ... Hmm... found a boost mpl rational_c :-) ...but no docs :-(
Patches welcome.
OK I have started on boost::mpl::rational_c. I have derived from that into boost::mpl::integral_rational_c.
I can't imagine what that would mean or why that would be needed. A rational number is by definition both: a. Not integral b. A ratio of integers.
In implementing that I need some promotion...so may try Fernando Cacciolas converter. OTOH Alexey Gurtovoys types_promotion_traits if all needs to be mpl.
I think you want Joel de Guzman's technology. You might search the message archives for his postings about it.
Other promotion metafunction implementations welcome. I seem to remember one candidate for the library but dont know where to find it. I would be happy to use that if possible.
From there I go to int_rational, long_rational etc I prefer int_rat but.... ok forget it :-)
Overkill, IMO, but it's your party.
Finally can use that to implement simple pow,root reciprocal etc. Should I do reciprocal<integral_c> --> integral_rational_c or is that a user thing?
Sorry, I don't understand the question.
Seriously though.. Perhaps that may be better because I am not using the operators to represent a compile-time operation, but the type returned as a result of the runtime operation... maybe that is an important distinction? And it would solve the problem...for me anyways:-)
I stand by the above. There are two distinct types of operations. Some are designed to return a compile time value. Some are designed to return a type.
MPL metafunctions only deal in types (which may be wrappers for numbers). That simplifies everything a lot.
I keep 'bumping into' this issue and I dont like it ! I suspect it occurs only when you start to specialise the operators for UDTs. It gets worse, I think Phil Richards uses plus where I would use multiplies. One good reason to pull the user level stuff out of the mpl namespace to prevent confusion.
Also incomprehensible to me.
Alternatively reserve mpl namespace for 'operators'. boost::mpl::math ?
Whatever you guys decide...
I think the MPL conventions are fine as-is, and probably should be followed.
Are there some written guidelines on these conventions or am I just meant to 'know' them? hmm..I seem to remember asking this before :-)
Just look back a little bit in the thread to Daniel Wallin's posting and I think you'll find the answer you seek. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote ...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
[snip]
OK I have started on boost::mpl::rational_c. I have derived from that into boost::mpl::integral_rational_c.
I can't imagine what that would mean or why that would be needed. A rational number is by definition both:
a. Not integral b. A ratio of integers.
That was a bait.;-) OK to hack Alexey Gurtovoys rational_c ? This message has been recorded etc.
In implementing that I need some promotion...so may try Fernando
Cacciolas
converter. OTOH Alexey Gurtovoys types_promotion_traits if all needs to be mpl.
I think you want Joel de Guzman's technology. You might search the message archives for his postings about it.
OK I need this in the library...btw so does mpl impl ! too much ad-hoc stuff for my likeing :-) [snip]
From there I go to int_rational, long_rational etc I prefer int_rat but.... ok forget it :-)
Overkill, IMO, but it's your party.
I'll make sure I go to bed early . :-)
Finally can use that to implement simple pow,root reciprocal etc. Should I do reciprocal<integral_c> --> integral_rational_c or is that a user thing?
Sorry, I don't understand the question.
sorted by your previous reply.
MPL metafunctions only deal in types (which may be wrappers for numbers). That simplifies everything a lot.
I'm going for naming members xx_value and xx_type. Any good ?... whats (rolling up my trouser leg) *traditional*. [snip]
Are there some written guidelines on these conventions or am I just meant to 'know' them? hmm..I seem to remember asking this before :-)
Just look back a little bit in the thread to Daniel Wallin's posting and I think you'll find the answer you seek.
This ? : " This is not the "traditional" use of trailing underscores. Normally they are used for keywords. int -> int_ bool -> bool_ etc. MPL uses tons of names that clashes with names in std. This is a problem for the user, not the library. -- Daniel Wallin " Cant see the reference or the link to written guidelines ...? I do see ... "Dont worry about the user" though ! hmm ...Ok to use the _t suffix then ..."traditional" way to represent a typedef . Started in the 70's I think ;-) BTW I declined joining the freemasons ...I prefer things to be open to everybody. BUT .......... mpl rocks! .......................... :-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
I can't imagine what that would mean or why that would be needed. A rational number is by definition both:
a. Not integral b. A ratio of integers.
That was a bait.;-) OK to hack Alexey Gurtovoys rational_c ? This message has been recorded etc.
I have no time for this. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote ...
Just look back a little bit in the thread to Daniel Wallin's posting and I think you'll find the answer you seek.
This ? : "
This is not the "traditional" use of trailing underscores. Normally they are used for keywords.
int -> int_ bool -> bool_
etc. MPL uses tons of names that clashes with names in std. This is a problem for the user, not the library."
Cant see the reference or the link to written guidelines ...?
Does it matter? If it makes you feel better, you can consider my post a "written guideline".
I do see ... "Dont worry about the user" though !
Yes, don't worry about the possibility that some user might decide to bring every name in reach into the global namespace. Prehaps you consider other peoples bad practice your problem, but it certainly isn't mine and I'm not willing to pay for it.
hmm ...Ok to use the _t suffix then ..."traditional" way to represent a typedef . Started in the 70's I think ;-)
I have no idea what you are trying to say.
BTW I declined joining the freemasons ...I prefer things to be open to everybody.
Again, I don't understand. -- Daniel Wallin
"Daniel Wallin" <dalwan01@student.umu.se> wrote
Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote ...
I do see ... "Dont worry about the user" though !
Yes, don't worry about the possibility that some user might decide to bring every name in reach into the global namespace. Prehaps you consider other peoples bad practice your problem, but it certainly isn't mine and I'm not willing to pay for it.
Presumably you would consider it a grave offence if examples of this bad practise 'using namespace mpl;' were to be found in the boost library itself? I am seriously not trying to be smart but I am beginning to think that mpl should not be exposed in the user interface of my library. Its just one more incomprehensible sea of error messages to an inexperienced user. regards Andy Little
Andy Little wrote:
"Daniel Wallin" <dalwan01@student.umu.se> wrote
Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote ...
I do see ... "Dont worry about the user" though !
Yes, don't worry about the possibility that some user might decide to bring every name in reach into the global namespace. Prehaps you consider other peoples bad practice your problem, but it certainly isn't mine and I'm not willing to pay for it.
Presumably you would consider it a grave offence if examples of this bad practise 'using namespace mpl;' were to be found in the boost library itself?
Yes, unless it's done locally in a function or a separate compilation unit of course. The point is that the user that introduces the name clashes by bringing in the names into the same namespace should deal with the problem. -- Daniel Wallin
"Daniel Wallin" <dalwan01@student.umu.se> wrote
Andy Little wrote:
"Daniel Wallin" <dalwan01@student.umu.se> wrote
Andy Little wrote:
Presumably you would consider it a grave offence if examples of this bad practise 'using namespace mpl;' were to be found in the boost library itself?
Yes, unless it's done locally in a function or a separate compilation unit of course. The point is that the user that introduces the name clashes by bringing in the names into the same namespace should deal with the problem.
If mpl is not exposed as part of the user interface, then there will be no temptation to do this. Which incidentally solves a lot of problems and renders the mpl operators in the title of this thread unnecessary for my library I have had some confusion about the purpose of (say) mpl::plus. When used like this: boost::mpl::plus<int_<1>,int_<1> >::type. It is a compile time operation on the internal values of the int_'s However I have been trying to use it like this: myClass x; myClass y; boost::mpl::plus<myClass,myClass>::type t = x+y; In this situation a different compile time function name would seem more suitable. result_of_plus<myClass,myClass>::type t = x+y; which has clarified only after reading Joel de Guzmans type-deduction.hpp header. Though perhaps this might work: result_of<myClass, '+' , myClass>::type t = x+y; or result_of< operator_<'+'>,myClass,myClass >::type t = x + y; maybe I'll experiment with that. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
When used like this:
boost::mpl::plus<int_<1>,int_<1> >::type.
It is a compile time operation on the internal values of the int_'s
No it isn't. The above is nonsense and won't compile. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Tue, Feb 03, 2004 at 07:12:34AM -0500, David Abrahams wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
When used like this:
boost::mpl::plus<int_<1>,int_<1> >::type.
It is a compile time operation on the internal values of the int_'s
No it isn't. The above is nonsense and won't compile.
Ok, I confess I haven't been following this thread, and also I don't know MPL well. But what's wrong with the above? #include <iostream> #include "boost/mpl/plus.hpp" #include "boost/mpl/int.hpp" using namespace boost::mpl; using std::cout; using std::endl; int main() { cout << plus< int_<1>, int_<1> >::type::value << endl; } seems to work and prints "2". -- -Brian McNamara (lorgon@cc.gatech.edu)
Brian McNamara <lorgon@cc.gatech.edu> writes:
On Tue, Feb 03, 2004 at 07:12:34AM -0500, David Abrahams wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
When used like this:
boost::mpl::plus<int_<1>,int_<1> >::type.
It is a compile time operation on the internal values of the int_'s
No it isn't. The above is nonsense and won't compile.
Ok, I confess I haven't been following this thread, and also I don't know MPL well. But what's wrong with the above?
#include <iostream> #include "boost/mpl/plus.hpp" #include "boost/mpl/int.hpp" using namespace boost::mpl; using std::cout; using std::endl; int main() { cout << plus< int_<1>, int_<1> >::type::value << endl; }
seems to work and prints "2".
Whoops; I was too hasty. What I read was: boost::mpl::plus<int_<_1>,int_<_1> >::type. ^ ^ Sorry everyone. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 07:26 PM 2/3/2004, Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote
boost::mpl::plus<int_<_1>,int_<_1> >::type.
I'd tend to avoid this type of thing personally... 17.4.3.1.2
The second bullet item in 17.4.3.1.2 only applies to the global namespace. --Beman
"Beman Dawes" <bdawes@acm.org> wrote in
At 07:26 PM 2/3/2004, Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote
boost::mpl::plus<int_<_1>,int_<_1> >::type.
I'd tend to avoid this type of thing personally... 17.4.3.1.2
The second bullet item in 17.4.3.1.2 only applies to the global namespace.
If that is what it is intended to mean then the wording could be improved. "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace". To me that reads Dont Use Leading Underscores. Period. Perhaps you need to lobby to have the wording changed to: "Each name that begins with an underscore is reserved to the implementation in the global namespace". Even then I think I would find little reason to make use of it. Whatever... I guess you have more important things to worry about at the moment so... NRE Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
To me that reads Dont Use Leading Underscores. Period.
Perhaps you need to lobby to have the wording changed to:
"Each name that begins with an underscore is reserved to the implementation in the global namespace".
Don't make work for the rest of us. If you care about the issue, perhaps you need to lobby. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ud68thd7w.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
To me that reads Dont Use Leading Underscores. Period.
Perhaps you need to lobby to have the wording changed to:
"Each name that begins with an underscore is reserved to the implementation in the global namespace".
Don't make work for the rest of us.
hmm... just pointing out the rules, which, if not followed, cause a large volume of macros and workarounds,obscure bugs and hence a lot of tedious and unnecessary work for somebody, but which, if followed, save that work for everybody. Rule actually reads: "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace".
If you care about the issue, perhaps you need to lobby.
Rule is fine as it stands AFAICS. Whatever ... There is a rational header in boost/mpl/math/rational_c.hpp. but has no functionality. Enclosed is an implementation with some functionality. regards Andy Little begin 666 rational_c.txt M#0HC:69N9&5F($)/3U-47TU03%]2051)3TY!3%]#7TA04%])3D-,541%1 T* M(V1E9FEN92!"3T]35%]-4$Q?4D%424].04Q?0U](4%!?24Y#3%5$140-"@T* M+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*+R\@8F]O<W0O M;7!L+W)A=&EO;F%L7V,N:'!P(&AE861E<B!F:6QE#0HO+R!3964@:'1T<#HO M+W=W=RYB;V]S="YO<F<@9F]R('5P9&%T97,L(&1O8W5M96YT871I;VXL(&%N M9"!R979I<VEO;B!H:7-T;W)Y+@T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+0T*+R\-"B\O($-O<'ER:6=H=" H8RD@,C P,"TP,@T*+R\@ M06QE:W-E>2!'=7)T;W9O>0T*+R\-"B\O(%!E<FUI<W-I;VX@=&\@=7-E+"!C M;W!Y+"!M;V1I9GDL(&1I<W1R:6)U=&4@86YD('-E;&P@=&AI<R!S;V9T=V%R M90T*+R\@86YD(&ET<R!D;V-U;65N=&%T:6]N(&9O<B!A;GD@<'5R<&]S92!I M<R!H97)E8GD@9W)A;G1E9"!W:71H;W5T(&9E92P@#0HO+R!P<F]V:61E9"!T M:&%T('1H92!A8F]V92!C;W!Y<FEG:'0@;F]T:6-E(&%P<&5A<G,@:6X@86QL M(&-O<&EE<R!A;F0@#0HO+R!T:&%T(&)O=&@@=&AE(&-O<'ER:6=H="!N;W1I M8V4@86YD('1H:7,@<&5R;6ES<VEO;B!N;W1I8V4@87!P96%R(&EN( T*+R\@ M<W5P<&]R=&EN9R!D;V-U;65N=&%T:6]N+B!.;R!R97!R97-E;G1A=&EO;G,@ M87)E(&UA9&4@86)O=70@=&AE( T*+R\@<W5I=&%B:6QI='D@;V8@=&AI<R!S M;V9T=V%R92!F;W(@86YY('!U<G!O<V4N($ET(&ES('!R;W9I9&5D(")A<R!I M<R(@#0HO+R!W:71H;W5T(&5X<')E<W,@;W(@:6UP;&EE9"!W87)R86YT>2X- M"@T*+R\@;6]D<R!B>2!-871T:&EA<R!38VAA8F5L+"!*86X@3&%N9V5R(&%N M9"!!;F1Y(&QI='1L90T*#0HC:6YC;'5D92 B8F]O<W0O<W1A=&EC7V%S<V5R M="YH<' B#0HC:6YC;'5D92 B8F]O<W0O;7!L+W9O:60N:'!P(@T*(VEN8VQU M9&4@(F)O;W-T+VUP;"]I9BYH<' B#0HC:6YC;'5D92 B8F]O<W0O;6%T:"]C M;VUM;VY?9F%C=&]R+FAP<"(-"B-I;F-L=61E(")B;V]S="]M<&PO<&QU<RYH M<' B#0HC:6YC;'5D92 B8F]O<W0O;7!L+VUI;G5S+FAP<"(-"B-I;F-L=61E M(")B;V]S="]M<&PO;75L=&EP;&EE<RYH<' B#0HC:6YC;'5D92 B8F]O<W0O M;7!L+V1I=FED97,N:'!P(@T*(VEN8VQU9&4@(F)O;W-T+VUP;"]N96=A=&4N M:'!P(@T*+R\@861D(" @(&]R+"!A;F0@971C#0H-"B\O(&-O;7!I;&4@=&EM M92!R871I;VYA;"!N=6UB97(-"B\O('5S:6YG(&UP;"!O<&5R871O<G,-"@T* M;F%M97-P86-E(&)O;W-T>VYA;65S<&%C92!M<&Q[#0H-"B @("!T96UP;&%T M93P-"B @(" @(" @='EP96YA;64@26YT96=E<E1Y<&4L#0H@(" @(" @($EN M=&5G97)4>7!E($XL#0H@(" @(" @($EN=&5G97)4>7!E($0-"B @(" ^#0H@ M(" @<W1R=6-T(')A=&EO;F%L7V,@.PT*?7TO+V)O;W-T.CIM<&P-"@T*;F%M M97-P86-E(&)O;W-T>VYA;65S<&%C92!M<&Q[#0H-"B @("!T96UP;&%T93P- M"B @(" @(" @='EP96YA;64@26YT96=E<E1Y<&4L#0H@(" @(" @($EN=&5G M97)4>7!E($XL#0H@(" @(" @($EN=&5G97)4>7!E($0@/2 Q#0H@(" @/@T* M(" @('-T<G5C="!R871I;VYA;%]C('L-"B @("!P<FEV871E.@T*(" @(" @ M(" -"B @(" @(" @<W1A=&EC(&-O;G-T($EN=&5G97)4>7!E('!O<U]N=6UE M7VEN( T*(" @(" @(" ]($X@/CT@," _($X@.B M3CL-"B @(" @(" @<W1A M=&EC(&-O;G-T($EN=&5G97)4>7!E('!O<U]D96YO;5]I;B -"B @(" @(" @ M/2!$(#X](# @/R!$(#H@+40[#0H-"B @(" @(" @+R\@<W1A=&EC7V=C9"!R M971U<FYS('5N<VEG;F5D(&QO;F<-"B @(" @(" @<W1A=&EC(&-O;G-T($EN M=&5G97)4>7!E(&=C9" ]('-T871I8U]C87-T/$EN=&5G97)4>7!E/B -"B @ M(" @(" @*&)O;W-T.CIM871H.CIS=&%T:6-?9V-D/ T*(" @(" @(" @(" @ M<W1A=&EC7V-A<W0\=6YS:6=N960@;&]N9SXH<&]S7VYU;65?:6XI+ T*(" @ M(" @(" @(" @<W1A=&EC7V-A<W0\=6YS:6=N960@;&]N9SXH<&]S7V1E;F]M M7VEN*0T*(" @(" @(" ^.CIV86QU92D[#0H-"B @(" @(" @<W1A=&EC(&-O M;G-T($EN=&5G97)4>7!E(&YU;65?:6X@#0H@(" @(" @(#T@*"!.("H@1" ^ M/2 P*0T*(" @(" @(" _('!O<U]N=6UE7VEN( T*(" @(" @(" Z("UP;W-? M;G5M95]I;CL@#0H@(" @<'5B;&EC.@T*(" @(" @("!S=&%T:6,@8V]N<W0@ M26YT96=E<E1Y<&4@;G5M97)A=&]R(#T@;G5M95]I;B]G8V0[#0H@(" @(" @ M('-T871I8R!C;VYS="!);G1E9V5R5'EP92!D96YO;6EN871O<B ]('!O<U]D M96YO;5]I;B]G8V0[#0H@(" @<')I=F%T93H-"B @(" @(" @='EP961E9B!R M871I;VYA;%]C(#P-"B @(" @(" @(" @($EN=&5G97)4>7!E+ T*(" @(" @ M(" @(" @;G5M97)A=&]R+ T*(" @(" @(" @(" @9&5N;VUI;F%T;W(-"B @ M(" @(" @/B!M87EB95]T>7!E.PT*(" @('!U8FQI8SH@#0H@(" @(" @("\O M<')E=F5N="!D:78@, T*(" @(" @("!T>7!E9&5F('1Y<&5N86UE(&EF7V,\ M#0H@(" @(" @(" @("!S=&%T:6-?8V%S=#QB;V]L/BAD96YO;6EN871O<BDL M#0H@(" @(" @(" @("!M87EB95]T>7!E+ T*(" @(" @(" @(" @=F]I9%\- M"B @(" @(" @/CHZ='EP92!T>7!E.PT*#0H@(" @(" @("\O*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ#0H@(" @(" @("\O($AI+"!Y;W4@9V5T M(&AE<F4@#0H@(" @(" @("\O(&EF(&1E;F]M:6YA=&]R(&ES('IE<F\@:64@ M,2\P#0H@(" @(" @($)/3U-47U-4051)0U]!4U-%4E0H9&5N;VUI;F%T;W(I M.PT*(" @(" @(" O+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BH- M"B @("!].PT*(" @#0H@(" @=&5M<&QA=&4\#0H@(" @(" @('1Y<&5N86UE M($EN=&5G97)4>7!E+ T*(" @(" @("!);G1E9V5R5'EP92!.+ T*(" @(" @ M("!);G1E9V5R5'EP92!$#0H@(" @/B -"B @("!S=')U8W0@;F5G871E/" - M"B @(" @(" @<F%T:6]N86Q?8SP-"B @(" @(" @(" @($EN=&5G97)4>7!E M+ T*(" @(" @(" @(" @3BP-"B @(" @(" @(" @($0-"B @(" @(" @/B - M"B @(" ^>R -"B @(" @(" @='EP961E9B!T>7!E;F%M92!R871I;VYA;%]C M/$EN=&5G97)4>7!E+"U.+$0^.CIT>7!E('1Y<&4[( T*(" @('T[#0H-"B @ M("!T96UP;&%T93P-"B @(" @(" @='EP96YA;64@26YT96=E<E1Y<&4L#0H@ M(" @(" O+R @='EP96YA;64@26YT96=E<E1Y<&4R+ T*(" @(" @("!);G1E M9V5R5'EP92!.,2P-"B @(" @(" @26YT96=E<E1Y<&4@1#$L#0H@(" @(" @ M($EN=&5G97)4>7!E($XR+ T*(" @(" @("!);G1E9V5R5'EP92!$,@T*(" @ M(#X@#0H@(" @<W1R=6-T('!L=7,\( T*(" @(" @(')A=&EO;F%L7V,\26YT M96=E<E1Y<&4L3C$L1#$^+ T*(" @(" @(')A=&EO;F%L7V,\26YT96=E<E1Y M<&4L3C(L1#(^( T*(" @(#Y[( T*(" @(" @("!T>7!E9&5F('1Y<&5N86UE M(')A=&EO;F%L7V,\#0H@(" @(" @(" @("!);G1E9V5R5'EP92P-"B @(" @ M(" @(" @($XQ("H@1#(@*R!.,B J($0Q+ T*(" @(" @(" @(" @1#$@*B!$ M,@T*(" @(" @(" ^.CIT>7!E('1Y<&4[( T*(" @('T[#0H@(" @#0H@(" @ M=&5M<&QA=&4\#0H@(" @(" @('1Y<&5N86UE($EN=&5G97)4>7!E+ T*(" @ M(" @("!);G1E9V5R5'EP92!.,2P-"B @(" @(" @26YT96=E<E1Y<&4@1#$L M#0H@(" @(" @($EN=&5G97)4>7!E($XR+ T*(" @(" @("!);G1E9V5R5'EP M92!$,@T*(" @(#X@#0H@(" @<W1R=6-T(&UI;G5S/ T*(" @(" @("!R871I M;VYA;%]C/$EN=&5G97)4>7!E+$XQ+$0Q/BP-"B @(" @(" @<F%T:6]N86Q? M8SQ);G1E9V5R5'EP92Q.,BQ$,CX@#0H@(" @/GL@#0H@(" @(" @('1Y<&5D M968@='EP96YA;64@<F%T:6]N86Q?8SP-"B @(" @(" @(" @($EN=&5G97)4 M>7!E+ T*(" @(" @(" @(" @3C$@*B!$,B M($XR("H@1#$L#0H@(" @(" @ M(" @("!$,2 J($0R#0H@(" @(" @(#XZ.G1Y<&4@='EP93L@#0H@(" @?3L- M"@T*(" @('1E;7!L871E/ T*(" @(" @("!T>7!E;F%M92!);G1E9V5R5'EP M92P-"B @(" @(" @26YT96=E<E1Y<&4@3C$L#0H@(" @(" @($EN=&5G97)4 M>7!E($0Q+ T*(" @(" @("!);G1E9V5R5'EP92!.,BP-"B @(" @(" @26YT M96=E<E1Y<&4@1#(-"B @(" ^( T*(" @('-T<G5C="!M=6QT:7!L:65S/ T* M(" @(" @("!R871I;VYA;%]C/$EN=&5G97)4>7!E+$XQ+$0Q/BP-"B @(" @ M(" @<F%T:6]N86Q?8SQ);G1E9V5R5'EP92Q.,BQ$,CX@#0H@(" @/GL@#0H@ M(" @(" @('1Y<&5D968@='EP96YA;64@<F%T:6]N86Q?8SP-"B @(" @(" @ M(" @($EN=&5G97)4>7!E+ T*(" @(" @(" @(" @3C$J3C(L#0H@(" @(" @ M(" @("!$,2I$,@T*(" @(" @(" ^.CIT>7!E('1Y<&4[( T*(" @('T[#0H- M"B @("!T96UP;&%T93P-"B @(" @(" @='EP96YA;64@26YT96=E<E1Y<&4L M#0H@(" @(" @($EN=&5G97)4>7!E($XQ+ T*(" @(" @("!);G1E9V5R5'EP M92!$,2P-"B @(" @(" @26YT96=E<E1Y<&4@3C(L#0H@(" @(" @($EN=&5G M97)4>7!E($0R#0H@(" @/B -"B @("!S=')U8W0@9&EV:61E<SP@#0H@(" @ M(" @('1Y<&5N86UE(')A=&EO;F%L7V,\26YT96=E<E1Y<&4L3C$L1#$^+ T* M(" @(" @("!T>7!E;F%M92!R871I;VYA;%]C/$EN=&5G97)4>7!E+$XR+$0R M/@T*(" @(#Y[#0H@(" @(" @('1Y<&5D968@='EP96YA;64@<F%T:6]N86Q? M8SP-"B @(" @(" @(" @(" @($EN=&5G97)4>7!E+ T*(" @(" @(" @(" @ M(" @3C$@*B!$,BP-"B @(" @(" @(" @(" @*"!.,2 ]/2 P("D@/R Q(#H@ M*$0Q("H@3C(I(" @#0H@(" @(" @(#XZ.G1Y<&4@='EP93L@#0H@(" @?3L- M"@T*?2!]+R]B;V]S=#HZ;7!L#0H-"B-E;F1I9B O+T)/3U-47TU03%]2051) M3TY!3%]#7TA04%])3D-,541%1 T*#0HO+R!T97-T#0HO+R-I;F-L=61E(")R M871I;VYA;%]C+FAP<"(-"B-I;F-L=61E(#QI;W-T<F5A;3X-"FEN="!M86EN M*"D@#0I[#0H@(" @=7-I;F<@8F]O<W0Z.FUP;#HZ<F%T:6]N86Q?8SL-"B @ M("!U<VEN9R!N86UE<W!A8V4@8F]O<W0[#0H-"B @("!T>7!E9&5F(')A=&EO M;F%L7V,\:6YT+#0L,CX@<F%T7V$[#0H@(" @<W1D.CIC;W5T(#P\(G)A=%]A M(#T@(B \/"!R871?83HZ;G5M97)A=&]R(#P\)R\G#0H@(" @/#P@<F%T7V$Z M.F1E;F]M:6YA=&]R(#P\)UQN)SL-"@T*(" @('1Y<&5D968@<F%T:6]N86Q? M8SQI;G0L,RPV/B!R871?8CL-"B @("!S=&0Z.F-O=70@/#PB<F%T7V(@/2 B M(#P\(')A=%]B.CIN=6UE<F%T;W(@/#PG+R<-"B @(" \/"!R871?8CHZ9&5N M;VUI;F%T;W(@/#PG7&XG.PT*#0H@(" @='EP961E9B!M<&PZ.G!L=7,\<F%T M7V$L<F%T7V(^.CIT>7!E(')A=%]P;'5S.PT*(" @('-T9#HZ8V]U=" \/")R M871?82 K(')A=%]B(#T@(B \/"!R871?<&QU<SHZ;G5M97)A=&]R(#P\)R\G M#0H@(" @/#P@<F%T7W!L=7,Z.F1E;F]M:6YA=&]R(#P\)UQN)SL-"@T*(" @ M('1Y<&5D968@;7!L.CIM:6YU<SQR871?82QR871?8CXZ.G1Y<&4@<F%T7VUI M;G5S.PT*(" @('-T9#HZ8V]U=" \/")R871?82 M(')A=%]B(#T@(B \/"!R M871?;6EN=7,Z.FYU;65R871O<B \/"<O)PT*(" @(#P\(')A=%]M:6YU<SHZ M9&5N;VUI;F%T;W(@/#PG7&XG.PT*#0H@(" @='EP961E9B!M<&PZ.FUU;'1I M<&QI97,\<F%T7V$L<F%T7V(^.CIT>7!E(')A=%]M=6QT:7!L:65S.PT*(" @ M('-T9#HZ8V]U=" \/")R871?82 J(')A=%]B(#T@(B \/"!R871?;75L=&EP M;&EE<SHZ;G5M97)A=&]R(#P\)R\G#0H@(" @/#P@<F%T7VUU;'1I<&QI97,Z M.F1E;F]M:6YA=&]R(#P\)UQN)SL-"@T*(" @('1Y<&5D968@;7!L.CID:79I M9&5S/')A=%]A+')A=%]B/CHZ='EP92!R871?9&EV:61E<SL-"B @("!S=&0Z M.F-O=70@/#PB<F%T7V$@+R!R871?8B ]("(@/#P@<F%T7V1I=FED97,Z.FYU M;65R871O<B \/"<O)PT*(" @(#P\(')A=%]D:79I9&5S.CID96YO;6EN871O M<B \/"=<;B<[#0H-"B @("!T>7!E9&5F(&UP;#HZ;F5G871E/')A=%]A/CHZ M='EP92!R871?;F5G7V$[#0H@(" @<W1D.CIC;W5T(#P\(BT@;F5G7V$@/2 B M(#P\(')A=%]N96=?83HZ;G5M97)A=&]R(#P\)R\G#0H@(" @/#P@<F%T7VYE M9U]A.CID96YO;6EN871O<B \/"=<;B<[#0H-"B-I9B P#0H@(" @+R\@8VAE M8VL@9&EV(# -"B @(" @='EP961E9B!R871I;VYA;%]C/&EN="PT+# ^(')A M=%]B860[#0H@(" @('-T9#HZ8V]U=" \/"!R871?8F%D.CID96YO;6EN871O ;<B \/"=<;B<[#0HC96YD:68@(" -"GT-"@T* ` end
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:bvnupa$h14$1@sea.gmane.org...
Though perhaps this might work:
result_of<myClass, '+' , myClass>::type t = x+y; or result_of< operator_<'+'>,myClass,myClass >::type t = x + y;
maybe I'll experiment with that.
Hows about this: regards Andy Little ---------------------------- // useage // binary_result<A,op,B>::type // type is the type of the result of A op B // op represented by operators in <functional> //Alexey Gurtovois promotion header // slightly hacked #include "types_promotion_traits.hpp" #include <functional> #include <iostream> template < typename A, /// just want to reuse the name from <functional> template<typename> class Binary_operator, typename B
struct binary_result{ // usually does the right thing typedef typename boost::types_promotion_traits< A, B >::type type; };
// specialisations for comp ops template< typename A, typename B
struct binary_result< A,std::less,B
{ typedef bool type; }; // udt ops struct Dummy1{}; struct Dummy2{}; struct Dummy3{};
template<> struct binary_result< Dummy1,std::multiplies,Dummy2
{ typedef Dummy3 type; };
int main() { std::cout << typeid(binary_result< char,std::plus,char >::type).name() <<'\n'; std::cout << typeid(binary_result< float,std::multiplies,int >::type).name() <<'\n'; std::cout << typeid(binary_result< char,std::less,double >::type).name() <<'\n'; std::cout << typeid(binary_result< Dummy1,std::multiplies,Dummy2 >::type).name() <<'\n'; } /* output VC7.1: int float bool struct Dummy3 */
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usmhuqwzd.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
[snip]
I think you want Joel de Guzman's technology. You might search the message archives for his postings about it.
I'm having trouble finding this. All I can find is a message saying that Joel de Guzman is working on it: BTW google cache message != to link messsage ??? regards Andy Little -------------------------------------------------------- Re: [boost] Re: type promotion/deduction again and AGAIN :-) [ Was:Re:Re:DimensionalAnalysisFeature Summary ] by Joel de Guzman other posts by this author Oct 17 2003 3:48PM messages near this date -------------------------------------------------------------------------- [boost] Dimensional Analysis Interest? | Re: [boost] Re: type promotion/deduction again and AGAIN :-) [ Was: Re:Re:DimensionalAnalysisFeature Summary ] Hi Y'all, Ok, thanks for your interest. I'll go work on it then. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net begin 666 arrow_left.gif M1TE&.#EA"0`-`+,)`/OR\;PT)]-X<.F\N/;EX]R3C.W)QLI<4[@F&?___P`` M`````````````````````"'Y! $```D`+ `````)``T```0@,,E)*ZFRG H. 9VI,1(-]4D"0XH&DXME,'4R=8&0*FZQ$`.P`` ` end begin 666 arrow_right.gif M1TE&.#EA"0`-`+,)`/OR\;PT)]-X<.F\N/;EX]R3C.W)QLI<4[@F&?___P`` M`````````````````````"'Y! $```D`+ `````)``T```0B,,E)$ZGS%)P. ;.D#E(8%!C0BR26@ZL"EIPE^8J9@P<SP6`0`[ ` end
Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message
I think you want Joel de Guzman's technology. You might search the message archives for his postings about it.
I'm having trouble finding this.
All I can find is a message saying that Joel de Guzman is working on it: BTW google cache message != to link messsage ???
It's in the boost sandbox. See type_deduction.hpp in boost/utility. libs/utility/type_deduction_tests.cpp -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Joel de Guzman" <joel@boost-consulting.com> wrote
Andy Little wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message
I think you want Joel de Guzman's technology. You might search the message archives for his postings about it.
I'm having trouble finding this.
[snip]
It's in the boost sandbox. See type_deduction.hpp in boost/utility. libs/utility/type_deduction_tests.cpp
Thanks... found it ! Very interesting header!. Like the 'result_of_plus<A,B>::type' etc a lot. That may be just what I'm looking for :-) Thanks again. regards Andy Little
participants (6)
-
Andy Little -
Beman Dawes -
Brian McNamara -
Daniel Wallin -
David Abrahams -
Joel de Guzman