🚀 go-pugleaf

"ian (i.) willmott" <willmott@bnr.ca> wrote:
>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?

    YES, if the rvalue is non-const..

>If so, isn't that an inconsistency, since member functions are passed an
>implicit reference to the object they are called for?


    In my personal opinion, YES.

>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?
>}

    1 is illegal, can't bind a non-const ref to an rvalue, 
       even a non-const one.
    2 is legal, you can call a non-const member function 
      on a non-const rvalue
    3 is illegal for the same reason as 1
    4 is legal

4 out of 4 right :-)


A more subtle question is whether 

     g1(const_cast<X&>(f()));

is legal, assuming g1 actually modifies its argument.
I think so -- all const objects can be 
hardware write protected by the implementation,
but the rvalue f() involved here is non-const, so
it _is_ legal to modify it.

>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?

    The argument is that it catches errors where you accidentally
modify a temporary (to no effect). In fact, doing exactly this
is a useful idiom, especially since the lifetime of temporaries
is now fixed (it wasn't in the ARM): it saves creating dummy 
arguments where you don't WANT modifications to persist in
some more permanent object.

   So there's a trade off I think ought to be a quality
of implementation issue.


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au




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