Dear Arkadiy, My implementation of result_of heavily relies on BOOST_LVALUE_TYPEOF. Is it a big problem just to let it stay in the library? Even being not documented in public interface. Best Regards, Sergey Bulygin "Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:<dstku0$2ic$1@sea.gmane.org>...
Hi.
It turned out that we can't provide the portable implementation of LVALUE_TYPEOF that would be both safe and useful.
The primary purpose of this feature would be to assist in creation of wrapper functions (possibly through the result_of). The current implementation cannot distinguish between const rvalues and lvalues, and so yields const T& instead of const T (on VC7.1+, for UDT, it's also volatile& instead of volatile, and volatile const& instead of volatile const). If used in a wrapper function, this would lead to a dangling reference.
An alternative would be to yield rvalue for anything other than T&, but this would not work with const T& where T is non-copyable (again, on MS for UDT -- also with volatile [const] T&).
There are some (non-portable) ways to do better, but those work only for vc and gcc. Returning different results on different compilers would make it useless for generic code which is the primary target of this feature.
I am pretty sure nobody depends on LVALUE_TYPEOF in 1.34...
So, unless there are some serious objections, we are not including LVALUE_TYPEOF into 1.34. If, at some point in the future, a better way is found to determine lvalueness, this feature can be added again.
Regards, Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Bulygin, Sergey" <Bulygin@nilitis.com> wrote
My implementation of result_of heavily relies on BOOST_LVALUE_TYPEOF. Is it a big problem just to let it stay in the library? Even being not documented in public interface.
The problem is that it is just NOT SAFE to implement the result_of in terms of LVALUE_TYPEOF :-(( IIUC, the primaty usage of result_of is in the wrapper functions, something like: template<class F> typename result_of<F>::type wrap0(F f) { // do something typename result_of<F>::type result = f(); // do something else return result; } If your result_of relies on LVALUE_TYPEOF, it would work fine most of the time... unless the return type is const rvalue, in which case it would result in undefined behavior at runtime :-( (this is because the result_of<F>::type would yield const R&. The initialization of the const reference with const rvalue would compile fine because of the life extension rules, but then the object would be destroyed on the function return, which would resilt in a dangling reference) As of now there is no known ways to deal with the problem at compile time, so it would inevitably result in a RUMTIME PROBLEM. A safer alternative would be to only distingush between non-const lvalues and everything else. This case would be "safer", but result in compile-time problems, most notably for const noncopyable lvalues. Also note that at least MSVC has additional similar problems with [const] volatile UDT rvalues. In short, LVALUE_TYPEOF has so many unresolved (or even unresolvable) issues, that I just do not believe it deserves to be in Boost. If you still think that you can somehow benefit from this facility in this or that form, I would be happy to assist you in defining your own customized version. Maybe along the way we'll be able to figure out how to implement the generic facility. At this point we would reintroduce the LVALUE_TYPEOF as a part of typeof library. Best regards, Arkadiy
participants (2)
-
Arkadiy Vertleyb -
Bulygin, Sergey