Result_of, described here
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html as a uniform
method for computing function object return values, seems to require
something that is not possible. It has been accepted as part of the Library
Technical Report (due to function<> and bind<> needing it), so that this
impossible feature will be incorporated into a standard seems odd if not
alarming. In particular, the section titled "Description" has a point list
of what this object must do in it's default incarnation (while allowing
client specializations):

> 1. If F is a function type, type is the return type of the function type
F.
This seems to be no problem. One can use some variant of type traits to
determine if F is a pointer, in which case odds are it's a function.

> 2. If F is a member function type, type is the return type of the member
function type F.
Again no problem, a simple type trait can determine this.

> 3. If F is a function object defined by the standard library, the method
of determining type is unspecified.
This seems odd. This should be rather obvious, and since all standard
library function types pre-TR are required to have a result_type typemember,
it seems as if this rule should not even be needed given rule 4...

> 4. If F is a class type with a member type result_type, type is
F::result_type.
Here's where things get crazy. How, exactly, is a library supposed to
determine the presense or absense of result_type in the class F? I have seen
many interesting and odd techniques for finding things out about classes,
but I have yet to see a way to determine this. If it ended here, that would
be ok, though. Anything not fitting these criteria would fail in an attempt
to use F::result_type.

> 5. If F is a class type with no member named result_type or if
F::result_type is not a type:
> ...
But now we have to do something if it's not present.

Am I missing something? The goal of this class is stated to be, essentially,
a stop-gap measure until typeof is added to the standard (at which point it
would be unneeded, but still useful for reverse compatibility with C++98).
However, as is, this class seems only fully possible with C++98 compilers
that implement a forward looking typeof extension (GCC, CodeWarrior).

So what exactly is an implementation that fully conforms expected to do? It
can degrade to only providing result_type for standard classes, and assuming
result<> for any non-pointer, non-standard container. Is that what the
intention was?

Graham.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Graham Batty wrote:
> Result_of, described here
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html as a uni=
form
> method for computing function object return values, seems to require
> something that is not possible. It has been accepted as part of the Lib=
rary
> Technical Report (due to function<> and bind<> needing it), so that thi=
s
> impossible feature will be incorporated into a standard seems odd if no=
t
> alarming. In particular, the section titled "Description" has a point l=
ist
> of what this object must do in it's default incarnation (while allowing
> client specializations):
>=20
 > [...]
 >
>>4. If F is a class type with a member type result_type, type is
>=20
> F::result_type.
> Here's where things get crazy. How, exactly, is a library supposed to
> determine the presense or absense of result_type in the class F? I have=
 seen
> many interesting and odd techniques for finding things out about classe=
s,
> but I have yet to see a way to determine this. If it ended here, that w=
ould
> be ok, though. Anything not fitting these criteria would fail in an att=
empt
> to use F::result_type.

It's possible to detect nested types. Rani Sharoni developed this=20
technique, see

http://groups.google.com/groups?selm=3Ddf893da6.0203170237.3760f3c4%40pos=
ting.google.com

Regards, Daniel

--=20
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Graham Batty" wrote:

> Here's where things get crazy. How, exactly, is a library supposed to
> determine the presense or absense of result_type in the class F?

Using SFINAE:

template <typename F>
struct has_result_type
{
    typedef char Yes;
    typedef double No;

    template <typename T> static Yes test(typename T::result_type* );
    template <typename T> static No test(...);

    enum { value = (sizeof(test<F>(0)) == sizeof(Yes)) };
};

--
Giovanni Bajo

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]