In article <CK5vBz.67q@ses.com>, jamshid@ses.com (Jamshid Afshar) writes:
|> In article <1994Jan20.225022.24260@is.morgan.com>,
|> Jerry Liebelson <jlieb@is.morgan.com> wrote:
|> >[...]
|>  // shortened example of Jerry's code
|>
|>  class Object {};
|>
|>  class ObjHolder {
|>      Object* obj;
|>  public:
|>      ObjHolder(Object& o) : obj(&o) {}
|>      operator Object & () { return *obj; }
|>  };
|>
|>  ObjHolder func (Object& o) {  return o; }
|>
|>  int main () {
|>      Object o;
|>      Object& oRef = func(o);  // THIS FAILS WITH LUCID lcc -XF
|>      return 0;
|>  }
|>
|>  8.4.3 aims to make sure that a non-const reference does not
|>  refer to a temporary (see commentary on top of p155).  Since
|>  `operator Object&()' can't return a temporary, the above code
|>  is not particularily error-prone.
|>

True, but what concerns me is that since func() returns a temporary, is it
right or wrong for compilers to assume that the reference being returned
via the temporary's Object& operator also refers to a temporary?

Certainly, as my example usage illustrates, such an assumption would not
always be true. But that doesn't mean the language or the standard
committee allows compilers to have the necessary latitude.

--
Jerry Liebelson
jlieb@is.morgan.com
73477.2740@compuserve.com

In article <1994Jan20.225022.24260@is.morgan.com> jlieb@is.morgan.com
(Jerry Liebelson) writes:

|>   Can someone tell me whether the following usage is definitely illegal
|> according to the latest C++ standards and whether compilers that implement
|> strict C++ rules should flag the usage as an error rather than a warning?

|> The question concerns the following line in the main() block at the bottom
|> of the code that follows:

|>                 A& aRef = func(a);

|> Lucid 3.0, for example, when using the -XF option which implements strict
|> C++ standards, flags this statement as an error with the message:
|> ____________________________________________________
|> E, testc.cc(52,25) const initializer: temporary used to initialize reference
|>                                 v
|> 52              A& aRef = func(a);
|> ____________________________________________________

|> Now. I can understand why this should be a warning, but is this usage now
|> considered absolutely illegal by the C++ Standards Committee?

This usage is considered absolutely illegal by the ARM, and by the
current version of the working draft of the standards committee.

There is some more general discussion (concerning the meaning of const
of an rvalue, etc.) which occasionally puts this into question.
However, given the rationale that Bjarne gives in the ARM for the
rule, which was apparently introduced as a result of practical
experience without it, I seriously doubt that a proposal which annuls
it would pass the full committee.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <1994Jan20.225022.24260@is.morgan.com>,
Jerry Liebelson <jlieb@is.morgan.com> wrote:
>[...]
 // shortened example of Jerry's code

 class Object {};

 class ObjHolder {
     Object* obj;
 public:
     ObjHolder(Object& o) : obj(&o) {}
     operator Object & () { return *obj; }
 };

 ObjHolder func (Object& o) {  return o; }

 int main () {
     Object o;
     Object& oRef = func(o);  // THIS FAILS WITH LUCID lcc -XF
     return 0;
 }

I believe your code is legal but I've had this same disagreement with
another compiler vendor.  Here's the arguments I used to successfully
get them to change their mind.  I believe they also posed the question
to the ANSI/ISO mailing list and apparently all or most of the
feedback agreed with me.

 The first paragraph of 8.4.3 says "A variable declared to be a T&
 [...]  must be initialized by an object of type T or an object that
 can be CONVERTED into a T."

 5.2: [user-defined conversions] may be applied by the compiler
 wherever a class object appears ... as an initializer ...

 8.4.3 aims to make sure that a non-const reference does not
 refer to a temporary (see commentary on top of p155).  Since
 `operator Object&()' can't return a temporary, the above code
 is not particularily error-prone.

Jamshid Afshar
jamshid@ses.com

In article <CK5vBz.67q@ses.com> jamshid@ses.com (Jamshid Afshar) writes:


...

               Object& oRef = func(o);  // THIS FAILS WITH LUCID lcc -XF

....

   I believe your code is legal but I've had this same disagreement with
   another compiler vendor.  Here's the arguments I used to successfully
   get them to change their mind.


For the record, there was no disagreement with Lucid.  Support entered
a query from Jerry Liebelson about this code on Jan 20.  I responded
on that day that the code was legal and the error message was due to a
bug in lcc.  The lcc bug was fixed in our internal development
compiler the next day.  I don't know when that response was
transmitted to Jerry Liebelson, but when I saw his post on Jan 21 I
responded by private email.

  -- Jerry Schwarz(jss@lucid.com)

Hi,
  Can someone tell me whether the following usage is definitely illegal
according to the latest C++ standards and whether compilers that implement
strict C++ rules should flag the usage as an error rather than a warning?

The question concerns the following line in the main() block at the bottom
of the code that follows:

                A& aRef = func(a);

Lucid 3.0, for example, when using the -XF option which implements strict
C++ standards, flags this statement as an error with the message:
____________________________________________________
E, testc.cc(52,25) const initializer: temporary used to initialize reference
                                v
52              A& aRef = func(a);
____________________________________________________

Now. I can understand why this should be a warning, but is this usage now
considered absolutely illegal by the C++ Standards Committee?

Here's the relevant code:

            class Object
            {
                public:
                    Object() {}

            };

            class A : public Object
            {
                public:
                    A() {}
            };


            class ObjHolder
            {
                public:
                    ObjHolder(Object&);
                    operator A & ();
                    operator A * ();

                private:
                    Object* obj;


            };

            inline ObjHolder::ObjHolder(Object& obj) : obj(&obj) {}

            inline ObjHolder::operator A & ()
            {
                cerr << "In operator A &" << endl;
                return *((A*)obj);
            }

            inline ObjHolder::operator A * ()
            {
                cerr << "In operator A *" << endl;
                return (A*)obj;
            }


            ObjHolder func (A& a)
            {
                return a;
            }

            void main ()
            {
                A a;
                A* aPtr = func(a);  // this is ok;
                A& aRef = func(a);  // BUT THIS FAILS WITH LUCID lcc -XF
            }


[For those wonder why this code is being used, it's a simplified version of
a more comprehensive Object Holder class that is used in a library of
heterogenerous classes to perform automatic, runtime type-checked downcasting.

But please don't respond with a side-discussion about the pros and cons
of single-object hierarchies and heterogeneous containers. ]


Thanks for the help,

--
Jerry Liebelson
jlieb@is.morgan.com
73477.2740@compuserve.com