runtime rvalue detection for Visual C++ 6.0
I was looking through the FOR_EACH - implementation, and noticed that it lacks rvalue detection for Visual C++ 6.0. After some investigation, I have found one very sleazy way of detecting rvalue-ness runtime without evaluating the argument more than once: # define BOOST_FOREACH_TYPEOF(COL) \ *(true ? 0 : &::boost::for_each::wrap(COL)) template<typename T> inline static_any<simple_variant<T const> > contain(int const& position_test,T const &t, bool const &, mpl::false_) { int rvalue_test=int(&t)-int(&position_test); bool rvalue=(rvalue_test<=8); return rvalue ? simple_variant<T const>(t) : simple_variant<T const>(&t); } Since this relies on the position of objects on the stack, there are probably cases where it will fail. Pointers (e.g. string constants) must be handled separately. Regards Peder
I was looking through the FOR_EACH - implementation, and noticed that it lacks rvalue detection for Visual C++ 6.0.
Not that I want to discourage your efforts, but really who bother anymore? I wouldn't waste to much efforts on portability issues with this compiler (unless you stuck with it already and need to keep it backward compatible) Gennadiy
Peder Holt wrote:
I was looking through the FOR_EACH - implementation, and noticed that it lacks rvalue detection for Visual C++ 6.0.
True, because a Microsoft "extension" allows rvalues to bind to non-const references.
After some investigation, I have found one very sleazy way of detecting rvalue-ness runtime without evaluating the argument more than once:
# define BOOST_FOREACH_TYPEOF(COL) \ *(true ? 0 : &::boost::for_each::wrap(COL))
This is dereferencing a null pointer!
template<typename T> inline static_any<simple_variant<T const> > contain(int const& position_test,T const &t, bool const &, mpl::false_) { int rvalue_test=int(&t)-int(&position_test); bool rvalue=(rvalue_test<=8);
return rvalue ? simple_variant<T const>(t) : simple_variant<T const>(&t); }
Since this relies on the position of objects on the stack, there are probably cases where it will fail. Pointers (e.g. string constants) must be handled separately.
I think I understand what you are trying to do, but it won't work in general. You are assuming that an rvalue's address will always have the same relation to an lvalue's address. But the lvalue could be in automatic storage (on the stack), in dynamic storage (on the heap) or in static storage (eg. a global object, possibly in another DLL). Besides the fact that comparing addresses in this way is bad karma, are you certain that all the above cases (automatic, dynamic, static) are handled? I'd rather wait until a better approach is found. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (3)
-
Eric Niebler -
Gennadiy Rozental -
Peder Holt