🚀 go-pugleaf

matt@cyclops5.berkeley.edu (Matt Austern) wrote:
>If a function returns an auto_ptr as an rvalue, it can't be used as
>the argument to a function that expects a non-const reference.  There
>are ways to get around this, but they're all a bit clumsy.

So the problem is that rvalues cannot be passed as non-const reference
parameters? Can you call a non-const member function on an object rvalue?
(Other than the destructor, which presumably will be called implicitly.)
If so, isn't that an inconsistency, since member functions are passed an
implicit reference to the object they are called for?

What part, if any, of the following code is legal under the draft standard?

class X {
    int i;
public:
    X(int);
    X(X &);
    int get(void);
    void set(int);
};

X f(void);
void g1(X &);
void g2(const X &);

void h(int i)
{
    X x(f());     // 1 - illegal?

    f().set(i);   // 2 - legal?
    g1(f());      // 3 - illegal?
    g2(f());      // 4 - legal?
}

My Cfront v3.03 compiler (HP) calls line 3 an anachronism, but doesn't mind
the others. I couldn't tell from sections [basic.lval] and [dcl.init.ref]
of the April draft (maybe this has changed in the September version)
exactly what the rule is, but the ARM has this to say (p154):

   If the initializer for a reference to type T is an lvalue of
   type T ... the reference will refer to the initializer;
   otherwise, if and only if the reference is to a const an object
   of type T will be created and initialized with the initializer.
   ...
   The distinction between references to consts and references to
   non-consts is a major change from earlier definitions of C++.
   The distinction was made to eliminate a major source of errors
   and surprises. Earlier, all references could be initialized to
   refer to temporary objects ...

Matt Austern:
>I don't know of any simply way to modify the definition of auto_ptr in
>the standard to avoid this difficulty: it seems to follow from the
>semantics of strict ownership.

It seems to me that this example tends to indicate that the prohibition of
non-const references to rvalues is a bad idea, at least for function
parameters. Section [basic.lval] suggests that you can in fact call
a non-const member function on a temporary object, so it's also inconsistent.
Why distinguish between member and non-member functions in this respect?

Surely there is a whole class of situations like this where the destructor
for a temporary has side effects which you may want to avoid or change by
modifying the object before it goes out of scope. I'm not sure what the ARM
means by "a major source of surprises"; if you pass a temporary as a reference
parameter, it's obviously going to evaporate after the function returns,
no matter what the function does or doesn't do to it.

I may be missing something here, but this seems like a really bad idea to me.
The ARM says "Naturally, this feature will be faded out of implementations
slowly, to avoid breaking working code", which sounds like an admission that
significant (and error-free) use has been made of it up until now. Maybe this
rule is what needs modification, rather than the definition of auto_ptr<T>.

Ian Willmott
Bell-Northern Research
Ottawa, Canada
(613)-763-9688
willmott@bnr.ca
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]