bind/lambda/phoenix and result_of
One happy day, we'll have auto and decltype... Until then, we have no reasonable way to declare the type of bind expressions. So I got to thinking, maybe something like this could be made to work: result_of<bind_(std::minus<int>, int, _1_)>::type f = bind(std::minus<int>(), 3, _1); For lambda, I guess we could do something like this: result_of<minus_(int, _1_)>::type f = 3 - _1; Does this direction make sense? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
One happy day, we'll have auto and decltype...
Until then, we have no reasonable way to declare the type of bind expressions. So I got to thinking, maybe something like this could be made to work:
result_of<bind_(std::minus<int>, int, _1_)>::type f = bind(std::minus<int>(), 3, _1);
For lambda, I guess we could do something like this:
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Any particular reason why BOOST_TYPEOF is not an option? Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
One happy day, we'll have auto and decltype...
Until then, we have no reasonable way to declare the type of bind expressions. So I got to thinking, maybe something like this could be made to work:
result_of<bind_(std::minus<int>, int, _1_)>::type f = bind(std::minus<int>(), 3, _1);
For lambda, I guess we could do something like this:
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Any particular reason why BOOST_TYPEOF is not an option?
It requires type registration, whereas this approach should not. That's the only reason. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
One happy day, we'll have auto and decltype...
Until then, we have no reasonable way to declare the type of bind expressions. So I got to thinking, maybe something like this could be made to work:
result_of<bind_(std::minus<int>, int, _1_)>::type f = bind(std::minus<int>(), 3, _1);
For lambda, I guess we could do something like this:
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Any particular reason why BOOST_TYPEOF is not an option?
It requires type registration, whereas this approach should not. That's the only reason.
Do you mean the type registration of bind/lambda types or user-defined types? Does result_of work with expression containing user-defined types with no additional requirements to these types? Regards, Arkadiy
"David Abrahams" wrote
"Arkadiy Vertleyb" wrote
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Any particular reason why BOOST_TYPEOF is not an option?
It requires type registration, whereas this approach should not. That's the only reason.
FWIW I would prefer to live with BOOST_TYPEOF and type registration. I have no doubt that registration will have its problems but only by familiarity will they be solved. Anyway somebody already proposed a similar looking alternative on comp.std.c++: http://tinyurl.com/gc7wn but with no response. Of course then, the proposer was ahead of his time. Now, BOOST_TYPEOF makes this functionality redundant regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Arkadiy Vertleyb" wrote
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Any particular reason why BOOST_TYPEOF is not an option?
It requires type registration, whereas this approach should not. That's the only reason.
FWIW I would prefer to live with BOOST_TYPEOF and type registration. I have no doubt that registration will have its problems but only by familiarity will they be solved.
Huh? How will familiarity with the problem help? I can't ask my library's users to register types. Anyway, I can understand you saying "I'm content to live with...," but really, why would you _prefer_ a world where people like me, who aren't so content, can't get satisfaction?
Anyway somebody already proposed a similar looking alternative on comp.std.c++:
That proposal addresses something quite a bit different from mine. He's trying to get the result type of invoking a function, whereas I'm trying to get the type of the lazy function object that's created by Boost.Bind and/or Boost.Lambda. The difference is that the former can't be achieved without builtin typeof or registration, whereas the latter can. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
I can't ask my library's users to register types.
Don't you have to ask them to do something else, so that result_of works?
No, we'd implement the necessary type computations to make result_of work. Remember, result_of takes types as inputs, not objects. So, result_of<bind_(std::minus<int>, int, _1_)>::type just requires that bind_ know about the types produced by boost::bind. And in result_of<minus_(int, _1_)>::type minus_ would just have to know how the operator- in the lambda library works. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
I can't ask my library's users to register types.
Don't you have to ask them to do something else, so that result_of works?
No, we'd implement the necessary type computations to make result_of work. Remember, result_of takes types as inputs, not objects.
So,
result_of<bind_(std::minus<int>, int, _1_)>::type
just requires that bind_ know about the types produced by boost::bind. And in
result_of<minus_(int, _1_)>::type
minus_ would just have to know how the operator- in the lambda library works.
I see. However BOOST_TYPEOF, although does require user type registration, has an advantage of much nicer syntax. Compare: result_of<minus_(minus_(int, _1_), _2_)>::type f = 3 - _1 - _2; with BOOST_AUTO(f, 3 - _1 - _2); It would be very nice to have lambda and bind types registered, so that the user at least have a choise. Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
However BOOST_TYPEOF, although does require user type registration, has an advantage of much nicer syntax. Compare:
result_of<minus_(minus_(int, _1_), _2_)>::type f = 3 - _1 - _2;
with
BOOST_AUTO(f, 3 - _1 - _2);
Yes, of course it does. You don't think the advantages of auto are lost on me, do you? Inside my library's implementation I'm willing to buy lack of registration with a slightly uglier syntax, because asking people to register types is completely untenable for me.
It would be very nice to have lambda and bind types registered, so that the user at least have a choise.
It's utterly irrelevant to me, since there's no way I'm going to ask users to register their types just so *I* can use typeof. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
However BOOST_TYPEOF, although does require user type registration, has an advantage of much nicer syntax. Compare:
result_of<minus_(minus_(int, _1_), _2_)>::type f = 3 - _1 - _2;
with
BOOST_AUTO(f, 3 - _1 - _2);
Yes, of course it does. You don't think the advantages of auto are lost on me, do you?
Inside my library's implementation I'm willing to buy lack of registration with a slightly uglier syntax, because asking people to register types is completely untenable for me.
It would be very nice to have lambda and bind types registered, so that the user at least have a choise.
It's utterly irrelevant to me, since there's no way I'm going to ask users to register their types just so *I* can use typeof.
I didn't realise it's for *your* code. The examples you provided didn't look to me generic enough to belong to a library. I do agree that usage of BOOST_TYPEOF in generic code should be avoided as long as there is a solution with no registration. Regards, Arkadiy
"David Abrahams" wrote
"Andy Little" writes:
"David Abrahams" wrote
"Arkadiy Vertleyb" wrote
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Any particular reason why BOOST_TYPEOF is not an option?
It requires type registration, whereas this approach should not. That's the only reason.
FWIW I would prefer to live with BOOST_TYPEOF and type registration. I have no doubt that registration will have its problems but only by familiarity will they be solved.
Huh? How will familiarity with the problem help? I can't ask my library's users to register types.
Why not? We all want decltype and auto in the language dont we? BOOST_TYPEOF is the closest we have. Show your users how to use it while we wait for language support. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Andy Little" writes:
"David Abrahams" wrote
"Arkadiy Vertleyb" wrote
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Any particular reason why BOOST_TYPEOF is not an option?
It requires type registration, whereas this approach should not. That's the only reason.
FWIW I would prefer to live with BOOST_TYPEOF and type registration. I have no doubt that registration will have its problems but only by familiarity will they be solved.
Huh? How will familiarity with the problem help? I can't ask my library's users to register types.
Why not? We all want decltype and auto in the language dont we? BOOST_TYPEOF is the closest we have. Show your users how to use it while we wait for language support.
Because I want to serve my users, not force them to learn about an interim solution that they won't need when the real feature comes out. Furthermore, it's _my_ library that needs result_of, so basically I would be telling users, "if you get a cryptic error message that looks like ___________, find some of the types in it and register them with this cryptic macro." I'd rather that people enjoy my library than have them vent frustration at me about how unusable Boost is. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote...
"Andy Little" writes:
"David Abrahams" wrote
"Andy Little" writes:
FWIW I would prefer to live with BOOST_TYPEOF and type registration. I have no doubt that registration will have its problems but only by familiarity will they be solved.
Huh? How will familiarity with the problem help? I can't ask my library's users to register types.
Why not? We all want decltype and auto in the language dont we? BOOST_TYPEOF is the closest we have. Show your users how to use it while we wait for language support.
Because I want to serve my users, not force them to learn about an interim solution that they won't need when the real feature comes out.
Not long to wait then, assuming upgrading is viable.... ;-) Meanwhile I have found Boost.Typeof really useful now.
Furthermore, it's _my_ library that needs result_of, so basically I would be telling users, "if you get a cryptic error message that looks like ___________, find some of the types in it and register them with this cryptic macro."
The error messages re lack of registration are not that bad IMO. The only problems I had was deciding what types to register when using mpl::transform IIRC.
I'd rather that people enjoy my library than have them vent frustration at me about how unusable Boost is.
The last time I tried to use lambda I seem to remember I had to do a lot more than just register my types with one cryptic macro. I had to map my own whacky type deduction scheme to lambdas whacky type deduction scheme. See below --^--> It would be nice if in future I registered my types once with Boost.Typeof , and then they work with lambda and any other library out of the box. Note: That would be nice in theory, but it seems that gcc has problems using expressions in return types, so maybe that leaves us back where we started,.. except that whatever type deduction wrapper is used it could then be implemented using Boost.Typeof. regards Andy Little --------------- **registering** with lambda http://www.boost.org/doc/html/lambda/extending.html (note this is from a previous version of pqs) #ifndef PQS_BOOST_LAMBDA_INTERFACE_HPP_INCLUDED #define PQS_BOOST_LAMBDA_INTERFACE_HPP_INCLUDED // Copyright (C) Andy Little 2004. // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. // This software is provided "as is" without express or implied warranty, // and with no claim as to its suitability for any purpose. #include "pqs/ct_quantity/ct_quantity_fwd.hpp" #include "pqs/operators/binary_operator_functors.hpp" #include "boost/lambda/lambda.hpp" namespace pqs{ template< typename Op> struct lambda_binary_operation_key; template<> struct lambda_binary_operation_key< boost::lambda::other_action< boost::lambda::assignment_action > >{ typedef pqs::operator_equals type; }; template<> struct lambda_binary_operation_key< boost::lambda::arithmetic_action< boost::lambda::plus_action > >{ typedef pqs::operator_plus type; }; // for stream output template<> struct lambda_binary_operation_key< boost::lambda::bitwise_action< boost::lambda::leftshift_action > >{ typedef pqs::operator_shift_left type; }; template<> struct lambda_binary_operation_key< boost::lambda::arithmetic_action< boost::lambda::minus_action > >{ typedef pqs::operator_minus type; }; template<> struct lambda_binary_operation_key< boost::lambda::arithmetic_action< boost::lambda::multiply_action > >{ typedef pqs::operator_multiplies type; }; template<> struct lambda_binary_operation_key< boost::lambda::arithmetic_action< boost::lambda::divide_action > >{ typedef pqs::operator_divides type; }; } namespace boost{namespace lambda{ template< typename Op, typename NamedAbstractQuantity, typename QuantityUnit, typename Value_type, typename Other > struct plain_return_type_2< Op, pqs::ct_quantity<NamedAbstractQuantity,QuantityUnit,Value_type>, Other >{ typedef typename pqs::lambda_binary_operation_key< Op >::type pqs_operator_type; typedef typename pqs_operator_type ::template result< pqs_operator_type( pqs::ct_quantity<NamedAbstractQuantity,QuantityUnit,Value_type>, Other) >::type type; }; template< typename Op, typename Other, typename NamedAbstractQuantity, typename QuantityUnit, typename Value_type > struct plain_return_type_2< Op, Other, pqs::ct_quantity<NamedAbstractQuantity,QuantityUnit,Value_type> >{ typedef typename pqs::lambda_binary_operation_key< Op >::type pqs_operator_type; typedef typename pqs_operator_type ::template result< pqs_operator_type( Other, pqs::ct_quantity<NamedAbstractQuantity,QuantityUnit,Value_type>) >::type type; }; template< typename Op, typename Abstract_idL, typename QuantityUnitL, typename Value_typeL, typename Abstract_idR, typename QuantityUnitR, typename Value_typeR > struct plain_return_type_2< Op, pqs::ct_quantity<Abstract_idL,QuantityUnitL,Value_typeL>, pqs::ct_quantity<Abstract_idR,QuantityUnitR,Value_typeR> >{ typedef typename pqs::lambda_binary_operation_key< Op >::type pqs_operator_type; typedef typename pqs_operator_type ::template result< pqs_operator_type( pqs::ct_quantity<Abstract_idL,QuantityUnitL,Value_typeL>, pqs::ct_quantity<Abstract_idR,QuantityUnitR,Value_typeR>) >::type type; }; }}//boost::lambda #endif
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
I can't ask my library's users to register types.
Why not? We all want decltype and auto in the language dont we? BOOST_TYPEOF is the closest we have. Show your users how to use it while we wait for language support.
Because I want to serve my users, not force them to learn about an interim solution that they won't need when the real feature comes out.
Not long to wait then, assuming upgrading is viable.... ;-)
Should I assume you're just baiting me, or what? How soon do you think everyone will be using a C++0x compiler supporting auto/decltype?
Meanwhile I have found Boost.Typeof really useful now.
I didn't say it wasn't useful; only that it's inappropriate for my purposes.
Furthermore, it's _my_ library that needs result_of, so basically I would be telling users, "if you get a cryptic error message that looks like ___________, find some of the types in it and register them with this cryptic macro."
The error messages re lack of registration are not that bad IMO.
Bad for you and bad for a user are two totally distinct things.
The only problems I had was deciding what types to register when using mpl::transform IIRC.
I'd rather that people enjoy my library than have them vent frustration at me about how unusable Boost is.
The last time I tried to use lambda I seem to remember I had to do a lot more than just register my types with one cryptic macro. I had to map my own whacky type deduction scheme to lambdas whacky type deduction scheme. See below --^-->
The difference is that IIUC lambda makes some reasonable assumptions when it doesn't know the answer -- assumptions that are appropriate to my use case, like that subtracting two values of one type yields the same type -- whereas typeof does not, and cannot. And anyway, as I've been saying, I'm *not talking about deducing the return type of an invoked lambda expression*. I'm just trying to capture the function type. Maybe Boost.Typeof is actually enough for that job; I don't know. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" writes:
I can't ask my library's users to register types.
Why not? We all want decltype and auto in the language dont we? BOOST_TYPEOF is the closest we have. Show your users how to use it while we wait for language support.
Because I want to serve my users, not force them to learn about an interim solution that they won't need when the real feature comes out.
Not long to wait then, assuming upgrading is viable.... ;-)
Should I assume you're just baiting me, or what?
I'm just exasperated. You seem to have completely reversed your position from previous discussions. For example see the "result_ofOp, operator should be a template parameter"," [typeof][result_of] Separated at Birth" threads on this newsgroup.
How soon do you think everyone will be using a C++0x compiler supporting auto/decltype?
I think it will be (say) 5 years or more? My opinion (but I am sure not an expert so may have this totally wrong) is that compiler implementors are more likely to incorporate the decltype/ auto functionality sooner if a substitute such as Boost.Typeof is being widely used. (Maybe the GNU guys will also get around to sorting out the problems with expressions in return types) The alternative using result_of(Op(...) ) seems to show the opposite, that we really dont need that functionality in the language, so why bother implementing it? That sums up what Boost.Typeof is about to me and I am really looking forward to seeing it as part of the boost distribution. I know it will cause problems ( error messages and registration) but I believe that we need to face up to that and learn/teach how to use Boost.Typeof as a precursor to getting language support ( and in many cases the Boost.Typeof macro does already or can be upgraded to something like the correct functionality without code changes) rather than creating yet more return type deduction mechanisms. [..]
And anyway, as I've been saying, I'm *not talking about deducing the return type of an invoked lambda expression*. I'm just trying to capture the function type. Maybe Boost.Typeof is actually enough for that job; I don't know.
Right. Sorry, the examples of the OP sure looked like return type deduction to me: " For lambda, I guess we could do something like this: result_of<minus_(int, _1_)>::type f = 3 - _1; " f is a functor here, isnt it? Assuming lambda and the type of _1 were registered, wouldnt Boost.Typeof give the correct result in this case? If it does then one watered down alternative might be to provide the typeof functionality as a non-default option I guess. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
For example see the "result_ofOp, operator should be a template parameter"," [typeof][result_of] Separated at Birth" threads on this newsgroup.
The ability to apply BOOST_TYPEOF to result_of highly depends on reliable lvalue detection. Unfortunately, as of now, and AFAIK, this can not be done. This is why LVALUE_TYPEOF was considered dangerous, and recently removed from the typeof library. Regards, Arkadiy
"David Abrahams" <dave@boost-consulting.com> wrote
Furthermore, it's _my_ library that needs result_of, so basically I would be telling users, "if you get a cryptic error message that looks like ___________, find some of the types in it and register them with this cryptic macro."
The error messages re lack of registration are not that bad IMO.
Bad for you and bad for a user are two totally distinct things.
Just a couple more questions: 1) Do you consider typeof error messages more cryptic than error messages produced by other boost libraries? Or STL? Is there such a thing as (portable) non-cryptic error message in template programming? 2) What is *cryptic* about registration macros? Also note that the user doesn't have to "find" the type in the message -- it's right there, saying something like TypeNotRegistered=blah<...; and it's always about user's own type if lambda types are indeed registered (if we are talking about lambda). And it seems to me that it's much easier to register lambda types than implement what you propose. I am not sure we are all on the same page here. AFAIU, the registration problem applies only to user-defined lambda functors. And if the user goes as far as implementing his own lambda functor, to register it with typeof is just a snap. And nothing "cryptic" about it. Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
Furthermore, it's _my_ library that needs result_of, so basically I would be telling users, "if you get a cryptic error message that looks like ___________, find some of the types in it and register them with this cryptic macro."
The error messages re lack of registration are not that bad IMO.
Bad for you and bad for a user are two totally distinct things.
Just a couple more questions:
1) Do you consider typeof error messages more cryptic than error messages produced by other boost libraries? Or STL? Is there such a thing as (portable) non-cryptic error message in template programming?
Irrelevant. The difference between a cryptic error message and *no* error message is dramatic.
2) What is *cryptic* about registration macros?
To the user, they have no obvious relationship to the user's immediate intention.
Also note that the user doesn't have to "find" the type in the message -- it's right there, saying something like TypeNotRegistered=blah<...; and it's always about user's own type if lambda types are indeed registered (if we are talking about lambda). And it seems to me that it's much easier to register lambda types than implement what you propose.
Maybe so. I'm beginning to think that I may have overestimated the amount of registration that would be required here. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Also note that the user doesn't have to "find" the type in the message -- it's right there, saying something like TypeNotRegistered=blah<...; and it's always about user's own type if lambda types are indeed registered (if we are talking about lambda). And it seems to me that it's much easier to register lambda types than implement what you propose.
Maybe so. I'm beginning to think that I may have overestimated the amount of registration that would be required here.
So, do we *have* typeof registrations for the lambda and bind libraries? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
So, do we *have* typeof registrations for the lambda and bind libraries?
Not AFAIK.
From the libraries currently in Boost, only spirit and xpressive had there types registered.
I would love to see lambda/bind to register their types, but this should be done by the library authors (or some volonteers intimately familiar with these libraries). Any help would be happily provided. Regards, Arkadiy
Arkadiy Vertleyb wrote:
"David Abrahams" <dave@boost-consulting.com> wrote
So, do we *have* typeof registrations for the lambda and bind libraries?
Not AFAIK.
From the libraries currently in Boost, only spirit and xpressive had there types registered.
I would love to see lambda/bind to register their types, but this should be done by the library authors (or some volonteers intimately familiar with these libraries). Any help would be happily provided.
This is the usual dependency problem with new (hence optional) infrastructure. People using TYPEOF would ideally just #include <boost/bind.hpp> and have it all work. People _not_ using TYPEOF would ideally #include <boost/bind.hpp> and _not_ have it include any other headers that are of no interest to them. Unfortunately we can't have it both ways. Can we?
"Peter Dimov" <pdimov@mmltd.net> wrote
Arkadiy Vertleyb wrote:
"David Abrahams" <dave@boost-consulting.com> wrote
So, do we *have* typeof registrations for the lambda and bind libraries?
Not AFAIK.
From the libraries currently in Boost, only spirit and xpressive had there types registered.
I would love to see lambda/bind to register their types, but this should be done by the library authors (or some volonteers intimately familiar with these libraries). Any help would be happily provided.
This is the usual dependency problem with new (hence optional) infrastructure. People using TYPEOF would ideally just #include <boost/bind.hpp> and have it all work. People _not_ using TYPEOF would ideally #include <boost/bind.hpp> and _not_ have it include any other headers that are of no interest to them. Unfortunately we can't have it both ways. Can we?
No, but I like the approach Eric used in xpressive: 1) have the types forward-declared; 2) register all the types in a separate file (something like bind_typeof.hpp). To use typeof then, one would have to include bind_typeof.hpp, and whichever headers from bind are needed. Regards, Arkadiy
David Abrahams wrote:
One happy day, we'll have auto and decltype...
Until then, we have no reasonable way to declare the type of bind expressions. So I got to thinking, maybe something like this could be made to work:
result_of<bind_(std::minus<int>, int, _1_)>::type f = bind(std::minus<int>(), 3, _1);
For lambda, I guess we could do something like this:
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Looks doable to me. But for more complex expressions, the result_of will be rather knotty because the prefix syntax will require some thinking to extract from the infix syntax of the actual lambda expression. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 5/9/06, David Abrahams <dave@boost-consulting.com> wrote:
One happy day, we'll have auto and decltype...
Until then, we have no reasonable way to declare the type of bind expressions. So I got to thinking, maybe something like this could be made to work:
result_of<bind_(std::minus<int>, int, _1_)>::type f = bind(std::minus<int>(), 3, _1);
For lambda, I guess we could do something like this:
result_of<minus_(int, _1_)>::type f = 3 - _1;
Does this direction make sense?
Hi, I would like to know if something like this were included in boost. It's only for boost that I want, and I don't want to pay for TYPEOF library. (MSVC8 only with emulation).
-- Dave Abrahams Boost Consulting www.boost-consulting.com
-- Felipe Magno de Almeida
"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> wrote in message
Hi, I would like to know if something like this were included in boost. It's only for boost that I want, and I don't want to pay for TYPEOF library. (MSVC8 only with emulation).
I havent noticed a great slow down in compilation times from using BOOST_TYPEOF with VC8. Have you found that it has a large effect on performance from using Boost.Typeof? There are other issues with Boost.Typeof but I havent found performance to be a problem FWIW regards Andy Little
participants (6)
-
Andy Little -
Arkadiy Vertleyb -
David Abrahams -
Felipe Magno de Almeida -
Joel de Guzman -
Peter Dimov