I am currently working on the library extension described in the TR1,
and I'm facing disturbing definitions that may or may not extend far
beyond their original meaning. Part of the problem is that when trying
to find the correct interpretation of the TR1 definition, I usually end
up with cases that I can't implement or that doesn't make much sense,
and the issue I want to describe here is one of them.
The TR1 requires reference_wrapper<> to inherit unary_function<> if the
wrapped type T inherit unary_function<> and binary_function<> is T
inherit binary_function<>. It also requires the implementor to
implement a weak result type which is either:
* the return type of the function/reference to a function/pointer to a
function/member function if T is one of these
* T::result_type if T defines it
* otherwise, result_type shall not be defined.
Now, it seems perfectly valid to wrap a class which inherit both
unary_function<> and binary_function<>, as the neither TR1 text nor the
next standard early draft text prohibits this. As a consequence,
reference_wrapper<T>::result_type can be quite difficult to define in
this case since it can be any of the following:
* T::result_type if it is defined
Pete Becker already told me that, in his meaning, the wrapped type
should not inherit both (on a recent comp.lang.c++ thread,
that simplifies the problem a lot, as I still don't foresee any legal
way to distinguish between the case were T::result_type is defined and
the case where T inherit the defintions of result_type from his parent
classes; but that's another problem). However, I still think that it
might be perfectly valid to define a wrapped type which inherit both
and provide two (or more) overload for operator(). In such case,
reference_wrapper<T>::result_type makes little sense, as the different
overloads might have different return types.
So here is the question: shall reference_wrapper<> handle such case?
If no, should the standard tells it explicitely?
If yes, how result_type should be defined? Should its definition be
Thanks for your patience,
-- Emmanuel Deloget, Artware
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:email@example.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/