"Ian McCulloch" <ianmcc@physik.rwth-aachen.de> wrote
Arkadiy Vertleyb wrote:
template<class T> T make();
template <class T> BOOST_TYPEOF_TPL(make<std::negate<T> >()(T())) operator-(T const& x) { return std::negate<T>()(x); }
This looks very attractive, and I'll probably und up using it somewhere; but in the particular application I'm working on, something like result_of (but allows SFINAE) will do fine. I guess its just a matter of what changes I'll need to make when we get decltype. With the result_of approach I could get rid of the nested result<> structs and/or result_of specializations, with the BOOST_TYPEOF approach I could simplify the forwarding function declarations. I'm not sure what is the better tradeoff.
We have BOOST_LVALUE_TYPEOF(), which attempts to mimique decltype. It's not *quite* decltype, however :-( Also, where built-in typeof exists, we forward to it, so you don't have to pay for all the emulation stuff. The main drawbacks are: 1) The need to register user-defined types/templates (although it's pretty simple); 2) Potential ODR non-conformance, because of automatic ID generation/use of unnamed namespace (although it doesn't seem to show up in any compilers we tested with, and we specifically try to cause it); 3) Slower compile times if complicated types are used; 4) Some (workaroundable) problems with standard iterator registration in Dinkumware STL (because of nested classes/non-deduced context) If you can live with the above four, I believe our typeof emulation is worth trying. (Please be awere, however, that the above code I provided may not compile in the current submission version, if you use VC71. It is subject to ETI bug workaround that I found trying to adapt your code, so thanks! It works with my local version that I plan to upload sometime before the review. If you do need it sooner, please let me know) Regards, Arkadiy