🚀 go-pugleaf

In article <9530713.8851@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> "ian (i.) willmott" <willmott@bnr.ca> writes:

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

|> Yes, 1 and 3 are ill-formed ("illegal"), while 2 and 4 are fine.

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

    [...]
|> This seems pretty clear to me - for a non-const reference, the
|> initializer must be an lvalue.  (If there was any doubt as to whether
|> this rule is intended to apply to copy constructors, it should be
|> dispelled by footnote 10 in this section.)

|> >My Cfront v3.03 compiler (HP) calls line 3 an anachronism, but doesn't mind

|> >the others.

|> Yes, there are quite a few compilers that detect the error in line 3
|> but fail to detect the error in line 1.  But I think these compilers
|> are just buggy; I think the draft standard definitely makes line 1
|> ill-formed.

One question: in the compilers which do detect the error in line 3,
but not in line 1, what is the actual code generated.  I suspect it is
not so much a case of the compiler binding a temporary to a non-const
reference, but one of the compiler not accepting
auto_ptr<T>::auto_ptr( auto_ptr<T>& ) as a copy constructor (since it
cannot be called), and *generating* its own copy constructor (with a
const parameter).

If this is the case, not only do you not get an error in the case of
line 1, you also get wrong code; both the temporary and the declared
variable think that they own the object pointed to.  When the
temporary is destructed (at the end of the statement), it will delete
the object, but the declared variable will continue to point to it.

I don't believe that the ARM was completely clear on this point; such
compilers may simply be implementing their interpretation of the ARM.
I would suggest, however, that given the above senario, the
implementors put this update at the highest priority.
--

James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung
---
[ 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. ]