This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/17435] [4.0 Regression] Binding a temporary of derived type to reference of base


------- Additional Comments From bangerth at dealii dot org  2004-09-13 15:43 -------
Yes, thanks. Specifically 12.2/5 may be read as indicating that the 
compiler may create a temporary of type Base when binding a Derived 
object to reference-to-base. 
 
The case I was really thinking about, though, is 8.5.3/5. The first 
enumeration does not apply (only lvalues as initializers), but the 
second one does: 
      --  If  the  initializer  expression is an rvalue, with T2 a class 
          type, and "cv1 T1" is reference-compatible with "cv2 T2,"  the 
          reference is bound in one of the following ways (the choice is 
          implementation-defined): 
 
          --  The reference is bound to the object  represented  by  the 
              rvalue  (see  _basic.lval_) or to a sub-object within that 
              object. 
 
          --  A temporary of type  "cv1 T2"  [sic]  is  created,  and  a 
              constructor  is  called  to  copy the entire rvalue object 
              into  the  temporary.   The  reference  is  bound  to  the 
              temporary or to a sub-object within the temporary.93) 
 
          The constructor that would be used to make the copy  shall  be 
          callable whether or not the copy is actually done.  [Example: 
 
             struct A { }; 
             struct B : public A { } b; 
             extern B f(); 
             const A& rca = f();             // Either bound to the A 
sub-object of the B rvalue, 
                                             //   or the entire B object is 
copied and the reference 
                                             //   is bound to the A sub-object 
of the copy 
 
           --end example] 
 
Alas, this pretty clearly states that gcc is in error and your expectations 
are correct -- I remembered that there was implementation leeway, but 
misremembered what the implementation was allowed to actually do. 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.0.0
      Known to work|                            |3.3.4 3.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17435


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]