Topic: private/protected copy constructor and reference parameters


Author: anhaeupl@late.e-technik.uni-erlangen.de (Bernd Anh\dupl)
Date: 1996/08/22
Raw View
According to 8.5.3 [dcl.init.ref] (end of) paragraph 8 of the April 95 WP,
initialization of a const reference from an rvalue requires that an
"appropriate copy constructor must be callable".

 1) Is "callable" just a synonym for "accessible" ?

 2) If it's a synonym for accessible, how can we use the
    slices and co. that come with valarrays:

  - slice_array have no public copy constructor.

  - they are only returned as rvalues from
   slice_array<T> valarray<T>::operator[](slice)

    Therefore we cannot make any use of slices, since

  - slice_arrays cannot be instantiated (no public constructor)

  - cannot be passed as values (no public constructor) nor
    as references which requires the initialization of
    a reference which in turn also requires a public constructor
    by 8.5.3.

 3.) What is the sense of requiring non-reference function return values
     to be rvalues?

  - We can even call non-constant member functions of such
    a rvalue (At least I could not find any statement
    in the WP that calling a member function is also
    equivalent to initialization of a reference or taking
    the address of the rvalue (which would be impossible,
    operator & requires lvalues) for initializing "this",
    but the WP explicitly states (3.10 [basic.lval]) that
    we can call member functions that can modify the
    object for rvalues).

  - Therefore compilers must be prepared to convert such
    rvalues to lvalues:

   class foo{
    ...
    foo & lvalue(){return *this;}
   }

   foo bar();

    now
   bar();

    yields an rvalue, whereas

   bar().lvalue();

    returns the same (rvalue-)object as lvalue.

  - Differentiating between modifiable and not modifiable
    objects (rvalues are nearly equivalent to non modifiable
    objects with the exception of member function call)
    should be made better be the use or not-use of const.

  - That would also solve the auto_ptr and similiar
    problems (see above; we do not need a copy constructor
    for binding references to lvalues).

--
Bernd Anhaeupl   Tel.:  +49 9131 857787
LATE - Uni Erlangen
Cauerstr. 7   Email: anhaeupl@late.e-technik.uni-erlangen.de
91058 Erlangen
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]