I'm posting these here partly because I'm interested in what people
think, but also because I hope if any of them turn out to be reasonable
suggestions, someone might tell me how to pass them on to the approriate
places (I know defect reports can be posted here, but do comments on TR1
count as such?)

Anyway, I have three main comments to make:

2.1.2.1 (reference_wrapper): If the class it derived from both
unary_function and binary_function, then should the reference_wrapper
also be derived from both? I can't see any reason you couldn't derive
from both unary_function and binary_function?
This also applies to 3.5 (Function template mem_fn)

In 3.4 3 (function objects): The last 2 points
"...
- if T is a class type with a member type result_type, then result_type
shall be a synonym for T::result_type
- otherwise result_type shall not be defined
"

Why not define for a class type that it is the return type of the
appropriate operator() ? It seems that this is trying to create a
slightly nasty hack to get around a problem which shouldn't be too hard
to fix in the compiler?

6.1(Tuple types) : This has been asked this before, but can Tuple have a
specialised swap which swaps each element? I think it was decided there
aren't any disadvantages to this (if exceptions are thrown, it might
leave you in a slightly worse state than if the nieve swap was
performed, but not really much worse).

Thank you

Chris

---
[ 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                       ]

chris wrote:

>
> 2.1.2.1 (reference_wrapper): If the class it derived from both
> unary_function and binary_function, then should the reference_wrapper
> also be derived from both? I can't see any reason you couldn't derive
> from both unary_function and binary_function?

If a class is derived from both unary_function and binary_function then
the nested member result_type will be ambiguous because it's defined in
both bases. More generally, though, the underlying design assumption in
the C++ standard is that function objects have a single operator(). TR1
loosens that assumption, but unary_function and binary_function are the
mechanism for communicating with function objects as defined in the C++
standard, so their uses in TR1 need to be compatible with the
assumptions in the C++ standard. It might be feasible to extend these
things to work with more general function objects, but nobody has done
the work to figure out how to make that work.

> This also applies to 3.5 (Function template mem_fn)

I don't see it. Each member function takes a fixed number of arguments.
When the number of arguments is 0 the mem_fn object can act like a unary
function; when the number of arguments is 1 the mem_fn object can act
like a binary function.

>
> In 3.4 3 (function objects): The last 2 points
> "...
> - if T is a class type with a member type result_type, then result_type
> shall be a synonym for T::result_type
> - otherwise result_type shall not be defined
> "
>
> Why not define for a class type that it is the return type of the
> appropriate operator() ? It seems that this is trying to create a
> slightly nasty hack to get around a problem which shouldn't be too hard
> to fix in the compiler?

Yes, that's the point: that list of alternatives applies when the
compiler can't determine the return type. Presumably this will be less
important in the future, but one of the decisions we made for TR1 is
that it should be implementable without compiler modifications. That
means compromising in some cases.

>
> 6.1(Tuple types) : This has been asked this before, but can Tuple have a
> specialised swap which swaps each element? I think it was decided there
> aren't any disadvantages to this (if exceptions are thrown, it might
> leave you in a slightly worse state than if the nieve swap was
> performed, but not really much worse).
>

I suppose the (unsatisfying) reason is that tuple is patterned after
std::pair, which doesn't have a swap function.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

In article <PYqdnQoBs-R2dkfcRVn-iw@rcn.net>,
 petebecker@acm.org (Pete Becker) wrote:

> > 6.1(Tuple types) : This has been asked this before, but can Tuple have a
> > specialised swap which swaps each element? I think it was decided there
> > aren't any disadvantages to this (if exceptions are thrown, it might
> > leave you in a slightly worse state than if the nieve swap was
> > performed, but not really much worse).
> >
>
> I suppose the (unsatisfying) reason is that tuple is patterned after
> std::pair, which doesn't have a swap function.

Both pair and tuple badly need a swap for C++0X.  Metrowerks currently
supplies both as an extension.

-Howard

---
[ 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                       ]

Pete Becker wrote:
..
>>
>> In 3.4 3 (function objects): The last 2 points
>> "...
>> - if T is a class type with a member type result_type, then
>> result_type shall be a synonym for T::result_type
>> - otherwise result_type shall not be defined
>> "
>>
>> Why not define for a class type that it is the return type of the
>> appropriate operator() ? It seems that this is trying to create a
>> slightly nasty hack to get around a problem which shouldn't be too
>> hard to fix in the compiler?
>
>
> Yes, that's the point: that list of alternatives applies when the
> compiler can't determine the return type. Presumably this will be less
> important in the future, but one of the decisions we made for TR1 is
> that it should be implementable without compiler modifications. That
> means compromising in some cases.
>
Thank you for helpful comments! I realise I'd just got a little confused
in some places :)

So if a compile could figure out the return type, then it can just
always use that, and ignore result_type? Or should result_type be used
if present? (Of course in theory result_type should be the return type
of operator(), but what exactly should happen if they differ? Is that
just undefined behaviour? Should it be stated perhaps that making
result_type something other than exactly the return type of operator()
can lead to undefined behaviour, or at least either result_type or the
return type of operator() being used?)

Thank you,

Chris
>>
>> 6.1(Tuple types) : This has been asked this before, but can Tuple have
>> a specialised swap which swaps each element? I think it was decided
>> there aren't any disadvantages to this (if exceptions are thrown, it
>> might leave you in a slightly worse state than if the nieve swap was
>> performed, but not really much worse).
>>
>
> I suppose the (unsatisfying) reason is that tuple is patterned after
> std::pair, which doesn't have a swap function.
>

---
[ 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                       ]

Chris wrote:
> So if a compile could figure out the return type, then it can just
> always use that, and ignore result_type?

That's what 3.4/2 requires: "The implementation may determine the _type_
member via any means that produces the exact type of the expression
f(t1, t2, ..., tN) for the given types."


  Or should result_type be used
> if present? (Of course in theory result_type should be the return type
> of operator(), but what exactly should happen if they differ? Is that
> just undefined behaviour? Should it be stated perhaps that making
> result_type something other than exactly the return type of operator()
> can lead to undefined behaviour, or at least either result_type or the
> return type of operator() being used?)
>

You're trying too hard. <g> This is the specification for result_of. It
tells you what result_of does. Its behavior is clear: if the compiler
can't determine the exact type it uses result_type.

result_of is used in a couple of places in the TR. In those places the
behavior is, as far as I know, clear. When a TR1 call wrapper object
that relies on result_of calls operator() on your object it gets
whatever type your operator() returns. The call wrapper, in turn,
returns the type given by result_of. The compiler has to convert the
types as appropriate. If the conversion isn't valid it's an error.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]