|
Boost : |
From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2006-02-15 11:04:05
"Bulygin, Sergey" <Bulygin_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk