Stanley Friesen [Contractor] wrote:
>
> >Citation, please?
>
> Unfortunately my copy of the standard is at home.
>

In 3.9.3 in the first paragraph describing const and volatile:

    The cv-qualified or cv-unqualified versions of a type are
    distinct types; however they shall have the same
    representation and alignment requirements
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>> >I try not to make *any* assumptions about the target environment,
>> >but stretching my imagination I can't think of a reason why a
>> >compiler would represent a T* differently from a T*const.
>>
>> Not only is there no reason to do so, the standard explicitly
>> forbids them to be different.

>Citation, please?

3.9.2 "Compound types" paragraph 3:

"Pointers to cv-qualified and cv-unqualified versions of
layout-compatible types shall have the same value representation
and alignment requirements."

--
Steve Clamage, stephen.clamage@sun.com

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

James Kuyper wrote in message <36A8C577.1AAC339C@wizard.net>...

>"Stanley Friesen [Contractor]" wrote:


>> [T* and T*const must have the same representation]

>Citation, please?

"The cv   qualified or cv   unqualified versions of a type ... shall have
the same representation and alignment requirements." (3.9.3p1)

For the related question:  Must (T*) and (T const*) have the same
representation?  The answer is also yes:


Any type is layout compatible with itself. (paraphrased 3.9p11)

"Pointers to cv   qualified and cv   unqualified versions (3.9.3) of
layout   compatible types shall have the same value representation and align
ment requirements (3.9)." (3.9.2p3)

HTH

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

In article <36A8C577.1AAC339C@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>"Stanley Friesen [Contractor]" wrote:
>> Not only is there no reason to do so, the standard explicitly
>> forbids them to be different.
>
>Citation, please?

Unfortunately my copy of the standard is at home.

The issue is discussed in either chapter 2 or 3, either in the section about
object representations, or in the section about general pointer types.  In
one of those places it specifically states that cv-qualifiers do not change
the object representation of pointers.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Stanley Friesen [Contractor]" wrote:
>
> In article <780hce$ko4$1@nnrp1.dejanews.com>,  <AllanW@my-dejanews.com> wrote:
> >I try not to make *any* assumptions about the target environment,
> >but stretching my imagination I can't think of a reason why a
> >compiler would represent a T* differently from a T*const.
>
> Not only is there no reason to do so, the standard explicitly
> forbids them to be different.

Citation, please?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <77og1m$c6c@netlab.cs.rpi.edu>,
  sbnaran@uiuc.edu wrote:
>
> On 13 Jan 1999 17:32:23 GMT, AllanW@my-dejanews.com
> >In article <slrn79li0j.lei.sbnaran@localhost.localdomain>,
> >Copying a pointer never has extra side-effects. So this is
> >already permitted due to the "as-if" rule; the side effects
> >would match an abstract machine that didn't have this
> >"optimization."
>
> Yes, but only if the representation of "T*" is the same
> as that of "T*const" -- that is, they have the same
> sizeof, the same numerical interpretation, etc.

Well, yes.

I try not to make *any* assumptions about the target environment,
but stretching my imagination I can't think of a reason why a
compiler would represent a T* differently from a T*const. In each
case, it is used to locate a T, and although the permitted
operations need not be the same, you can't assume that a non-null
T*const points to a T that was declared const.

Further, there's a practical requirement that conversion from T*
to T*const is very fast; if this were not true, then const
functions and pretty much any other use of const would incur a
run-time penalty. The fastest conversion between two pointer types
occurs when they have identical representation; in that situation,
the compiler needs only to decide that the pointer is the new type,
and it is.

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

In article <780hce$ko4$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:

> In article <77og1m$c6c@netlab.cs.rpi.edu>,
>   sbnaran@uiuc.edu wrote:
...
> > Yes, but only if the representation of "T*" is the same
> > as that of "T*const" -- that is, they have the same
> > sizeof, the same numerical interpretation, etc.
...
> I try not to make *any* assumptions about the target environment,
> but stretching my imagination I can't think of a reason why a
> compiler would represent a T* differently from a T*const. In each
> case, it is used to locate a T, and although the permitted
> operations need not be the same, you can't assume that a non-null
> T*const points to a T that was declared const.
>
> Further, there's a practical requirement that conversion from T*
> to T*const is very fast; if this were not true, then const
> functions and pretty much any other use of const would incur a
> run-time penalty. The fastest conversion between two pointer types
> occurs when they have identical representation; in that situation,
> the compiler needs only to decide that the pointer is the new type,
> and it is.

Another fact, perhaps the most convincing (for same representation), is
that you can have a pointer to a T* const, that really points to a T*.

    struct T { void foo(); };

    void use_pp( T* const* pp )
    {
        (**pp).foo();
    }

    int main()
    {
        T t;

        T* const cp = &t;
        use_pp( &cp );

        T* p = &t;
        use_pp( &p );
    }

If they had different representations, then a T* const* would have to
carry extra type information, and, at run-time, select the proper access
method. I think this would be unreasonable in any actual implementation.

--
"I don't like my edges rounded off" - Ani DiFranco

Gargantua Blargg | blargg@flash.net | http://www.flash.net/~blargg/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <780hce$ko4$1@nnrp1.dejanews.com>,  <AllanW@my-dejanews.com> wrote:
>I try not to make *any* assumptions about the target environment,
>but stretching my imagination I can't think of a reason why a
>compiler would represent a T* differently from a T*const.

Not only is there no reason to do so, the standard explicitly
forbids them to be different.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:
>
> AllanW@my-dejanews.com wrote in message
> <77gqbb$f8s$1@nnrp1.dejanews.com>...
>
> >Copying a pointer never has extra side-effects. So this is
> >already permitted due to the "as-if" rule; the side effects
> >would match an abstract machine that didn't have this
> >"optimization."
>
> Not quite.  Copying a pointer can modify a global or an argument (the
> pointer).
>
> int* Foo(int*& x)
> {
>   static int i;
>   static int j;
>
>   int* result = &i;
>   x = &j;
>   return result;
> }
>
> int* p = Foo(p);
>
> I believe this is conforming (it is legal to modify POD before it is
> constructed).  If 'result' is an alias for 'p' (NRVO) this would
> incorrectly leave p pointing at j.

Your scenario involves _two_ optimisations:

- The NRVO optimisation makes the return value (an unnamed temporary)
  equivalent to result (it "names" that return value "result").
  More exactly, instead of creating that temporary, it uses result
  directly (12.8/15, sentence (ii)).
- The second optimisation avoids the copy of that return value
  by making that temporary return value the same as p. But: Due
  to the NRVO, the return value is not an unnamed temporary - it's
  the named variable "result" (12.8/15, sentence (i)).

In article <slrn79li0j.lei.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain> writes
>I'm somewhat confused about this business of
>cv-unqualified types.  Are they saying that if
>the local object has type "T" and the return has
>type "const T", that the return value
>optimization can't be applied?  Eg,

No IMO just the reverse, it is saying 'ignore any cv qualification' and
look at the underlying types.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn79q6eq.abk.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain> writes
>Yes, but only if the representation of "T*" is the same
>as that of "T*const" -- that is, they have the same
>sizeof, the same numerical interpretation, etc.

I suppose that they might be different but I find it hard to accept.
const and volatile are really concerned with compile time behaviour.
Runtime objects do not carry cv qualification (that was discussed and
firmly rejected by WG21 & J16 when discussing RTTI).  While static
behaviour can depend on cv qualification (via function overloading)
dynamic behaviour, to the best of my knowledge, cannot.

As long as an appropriate copy ctor exists and is accessible it can be
optimised away when return by value is used.  Of course if the
programmer chooses to disallow copying of const qualifed instances the
compiler will generate an error.  e.g.

struct X {
// anything
        X (X &);
};

X fn(){ X const x;
// anything
return x;       // ERROR
}



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 13 Jan 1999 17:32:23 GMT, AllanW@my-dejanews.com
> >In article <slrn79li0j.lei.sbnaran@localhost.localdomain>,
>
> >>   (i) Whenever a temporary class object is copied
> >>   using a copy constructor, and this object and the
> >>   copy have the same cv-unqualified type, an
> >>   implementation is free to treat the original and
> >>   the copy as two different ways of referring to
> >>   the same object and not perform a copy at all,
> >>   even if the class copy constructor or destructor
> >>   have side effects.
>
> >I'm pretty sure that "the cv-unqualified type of ... is the same as ..."
> >means that the two types must match, EXCEPT for the const and volatile
> >qualifiers. Which means that type T matches type const T, but does not
> >match type U.
>
> Yes, I realized after posting that cv-qualified might be
> different from cv-unqualified.

The text in the std simply mean that cv-qualifiers aren't
considered relevant for this optimisation.

const T foo () { return T(); } // optimisation possible
T foo () { return T(); } // optimisation possible
T foo () { const T x; return x; } // optimisation possible

> Yes, but only if the representation of "T*" is the same
> as that of "T*const" -- that is, they have the same
> sizeof, the same numerical interpretation, etc.

And it's the case.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn79q6eq.abk.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain> writes
>Yes, but only if the representation of "T*" is the same
>as that of "T*const" -- that is, they have the same
>sizeof, the same numerical interpretation, etc.

I suppose that they might be different but I find it hard to accept.
const and volatile are really concerned with compile time behaviour.
Runtime objects do not carry cv qualification (that was discussed and
firmly rejected by WG21 & J16 when discussing RTTI).  While static
behaviour can depend on cv qualification (via function overloading)
dynamic behaviour, to the best of my knowledge, cannot.

As long as an appropriate copy ctor exists and is accessible it can be
optimised away when return by value is used.  Of course if the
programmer chooses to disallow copying of const qualifed instances the
compiler will generate an error.  e.g.

struct X {
// anything
        X (X &);
};

X fn(){ X const x;
// anything
return x;       // ERROR
}



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Jan 1999 17:32:23 GMT, AllanW@my-dejanews.com
>In article <slrn79li0j.lei.sbnaran@localhost.localdomain>,

>>   (i) Whenever a temporary class object is copied
>>   using a copy constructor, and this object and the
>>   copy have the same cv-unqualified type, an
>>   implementation is free to treat the original and
>>   the copy as two different ways of referring to
>>   the same object and not perform a copy at all,
>>   even if the class copy constructor or destructor
>>   have side effects.

>I'm pretty sure that "the cv-unqualified type of ... is the same as ..."
>means that the two types must match, EXCEPT for the const and volatile
>qualifiers. Which means that type T matches type const T, but does not
>match type U.

Yes, I realized after posting that cv-qualified might be
different from cv-unqualified.  So "T" is not equivalent
to "const T" by cv-qualified.  But "T" is (perhaps?)
equivalent to "const T" by cv-unqualified.  Although
"const T" is not equivalent to "T" by cv-unqualified.
Is this right?  Can you give a precise definition of
'cv-unqualified'?  Eg, does this always force a call
to the copy constructor upon return (ie, the return
value optimization does not apply), and why:

  T f() { const T out; return out; }


>Copying a pointer never has extra side-effects. So this is
>already permitted due to the "as-if" rule; the side effects
>would match an abstract machine that didn't have this
>"optimization."

Yes, but only if the representation of "T*" is the same
as that of "T*const" -- that is, they have the same
sizeof, the same numerical interpretation, etc.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in message
<77gqbb$f8s$1@nnrp1.dejanews.com>...

>Copying a pointer never has extra side-effects. So this is
>already permitted due to the "as-if" rule; the side effects
>would match an abstract machine that didn't have this
>"optimization."


Not quite.  Copying a pointer can modify a global or an argument (the
pointer).

int* Foo(int*& x)
{
  static int i;
  static int j;

  int* result = &i;
  x = &j;
  return result;
}

int* p = Foo(p);

I believe this is conforming (it is legal to modify POD before it is
constructed).  If 'result' is an alias for 'p' (NRVO) this would
incorrectly leave p pointing at j.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Jan 1999 17:32:23 GMT, AllanW@my-dejanews.com
>In article <slrn79li0j.lei.sbnaran@localhost.localdomain>,

>>   (i) Whenever a temporary class object is copied
>>   using a copy constructor, and this object and the
>>   copy have the same cv-unqualified type, an
>>   implementation is free to treat the original and
>>   the copy as two different ways of referring to
>>   the same object and not perform a copy at all,
>>   even if the class copy constructor or destructor
>>   have side effects.

>I'm pretty sure that "the cv-unqualified type of ... is the same as ..."
>means that the two types must match, EXCEPT for the const and volatile
>qualifiers. Which means that type T matches type const T, but does not
>match type U.

Yes, I realized after posting that cv-qualified might be
different from cv-unqualified.  So "T" is not equivalent
to "const T" by cv-qualified.  But "T" is (perhaps?)
equivalent to "const T" by cv-unqualified.  Although
"const T" is not equivalent to "T" by cv-unqualified.
Is this right?  Can you give a precise definition of
'cv-unqualified'?  Eg, does this always force a call
to the copy constructor upon return (ie, the return
value optimization does not apply), and why:

  T f() { const T out; return out; }


>Copying a pointer never has extra side-effects. So this is
>already permitted due to the "as-if" rule; the side effects
>would match an abstract machine that didn't have this
>"optimization."

Yes, but only if the representation of "T*" is the same
as that of "T*const" -- that is, they have the same
sizeof, the same numerical interpretation, etc.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in message
<77gqbb$f8s$1@nnrp1.dejanews.com>...

>Copying a pointer never has extra side-effects. So this is
>already permitted due to the "as-if" rule; the side effects
>would match an abstract machine that didn't have this
>"optimization."


Not quite.  Copying a pointer can modify a global or an argument (the
pointer).

int* Foo(int*& x)
{
  static int i;
  static int j;

  int* result = &i;
  x = &j;
  return result;
}

int* p = Foo(p);

I believe this is conforming (it is legal to modify POD before it is
constructed).  If 'result' is an alias for 'p' (NRVO) this would
incorrectly
leave p pointing at j.




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn79q6eq.abk.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain> writes
>Yes, but only if the representation of "T*" is the same
>as that of "T*const" -- that is, they have the same
>sizeof, the same numerical interpretation, etc.

I suppose that they might be different but I find it hard to accept.
const and volatile are really concerned with compile time behaviour.
Runtime objects do not carry cv qualification (that was discussed and
firmly rejected by WG21 & J16 when discussing RTTI).  While static
behaviour can depend on cv qualification (via function overloading)
dynamic behaviour, to the best of my knowledge, cannot.

As long as an appropriate copy ctor exists and is accessible it can be
optimised away when return by value is used.  Of course if the
programmer chooses to disallow copying of const qualifed instances the
compiler will generate an error.  e.g.

struct X {
// anything
        X (X &);
};

X fn(){ X const x;
// anything
return x;       // ERROR
}



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 13 Jan 1999 17:32:23 GMT, AllanW@my-dejanews.com
> >In article <slrn79li0j.lei.sbnaran@localhost.localdomain>,
>
> >>   (i) Whenever a temporary class object is copied
> >>   using a copy constructor, and this object and the
> >>   copy have the same cv-unqualified type, an
> >>   implementation is free to treat the original and
> >>   the copy as two different ways of referring to
> >>   the same object and not perform a copy at all,
> >>   even if the class copy constructor or destructor
> >>   have side effects.
>
> >I'm pretty sure that "the cv-unqualified type of ... is the same as ..."
> >means that the two types must match, EXCEPT for the const and volatile
> >qualifiers. Which means that type T matches type const T, but does not
> >match type U.
>
> Yes, I realized after posting that cv-qualified might be
> different from cv-unqualified.

The text in the std simply mean that cv-qualifiers aren't
considered relevant for this optimisation.

const T foo () { return T(); } // optimisation possible
T foo () { return T(); } // optimisation possible
T foo () { const T x; return x; } // optimisation possible

> Yes, but only if the representation of "T*" is the same
> as that of "T*const" -- that is, they have the same
> sizeof, the same numerical interpretation, etc.

And it's the case.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn79li0j.lei.sbnaran@localhost.localdomain>,
  sbnaran@uiuc.edu wrote:
>   (i) Whenever a temporary class object is copied
>   using a copy constructor, and this object and the
>   copy have the same cv-unqualified type, an
>   implementation is free to treat the original and
>   the copy as two different ways of referring to
>   the same object and not perform a copy at all,
>   even if the class copy constructor or destructor
>   have side effects.
>
>   (ii) For a function with a class return type, if
>   the expresssion in the return statement is the
>   name of a local object, and the cv-unqualified
>   type of the local object is the same as the
>   function return value, an implementation is
>   permitted to omit creating the temporary object
>   to hold the function return value, even if the
>   class copy constructor or destructor has side
>   effects.
>
>   (iii) In these cases, the object is destroyed at
>   the later of times when the original and the copy
>   would have been destroyed without the
>   optimization.
[...]
> I'm somewhat confused about this business of
> cv-unqualified types.  Are they saying that if
> the local object has type "T" and the return has
> type "const T", that the return value
> optimization can't be applied?  Eg,

I'm pretty sure that "the cv-unqualified type of ... is the same as ..."
means that the two types must match, EXCEPT for the const and volatile
qualifiers. Which means that type T matches type const T, but does not
match type U.

> As for pointer types, who cares whether the
> return value optimization is applied?  After
> all, copying a pointer is so cheap anyway.
> Eg,
>    T const * f() {
>       T * out=0;
>       return const_cast<T const*>(out); // copy required?
>    }
> As 'out' and the return value don't have the same
> cv qualified type, a call to the copy constructor
> is forced.  But we're copying pointers anyway, and
> the copy is inexpensive.  But if pointers of type
> "T *" and type "T const *" have the same
> representation, I don't see why the compiler apply
> the return value optimization.  Eg, suppose that
> sizeof(T*)==sizeof(T const *)==4.  Then the variable
> 'out' could be created directly in the return
> space.  IOW, the optimization should still apply.

Copying a pointer never has extra side-effects. So this is
already permitted due to the "as-if" rule; the side effects
would match an abstract machine that didn't have this
"optimization."

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn79li0j.lei.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain> writes
>I'm somewhat confused about this business of
>cv-unqualified types.  Are they saying that if
>the local object has type "T" and the return has
>type "const T", that the return value
>optimization can't be applied?  Eg,

No IMO just the reverse, it is saying 'ignore any cv qualification' and
look at the underlying types.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[ comp.std.c++ added to newsgroups, as my question is about what the
standard allows]

Jamie Hamilton wrote in message <773gk4$5m7$1@news1.Radix.Net>...
>
>Marcus Lindblom wrote in message <36920588.0@d2o54.telia.com>...
>>Hi!
>>
>>(newbie c++ question)
>>
>>I have a function that looks like this:
>>
>>ndMatrix operator*(ndMatrix &)
>>{
>>    ndMatrix temp;
>>    ....
>>    return ndMatrix;
>>}
>>
>
>
>One practical suggestion that was mentioned but not much explained in
>this discussion is that in order to get the best optimizations, you
>generally
>want functions to return an unnamed temporary instead of declaring a
>named
>variable and then returning it. E.g.:
>(some minor corrections to your code included)
>
>ndMatrix ndMatrix::operator*(const ndMatrix & matrix) const
>{
>    return ndMatrix(*this, matrix);
>}
>
>in which case you would need a constructor that takes two args
>and does the multiplying. Unfortunately, this can be confusing
>when you have multiple binary operators, so you might have to
>be creative with your constructors and the arguments they take.
>But the upside is that you won't get the extra copying in any
>decent optimizing compiler.
>


I was under the impression that the standard disallowed this
optimization
now (unnamed returnvalue optimization), although it used to be a common
optimization (cfront). Instead the compiler is now allowed to optimize
when
there is a named variabele (named returnvalue optimization).

Am I correct or is Jamie correct?

Thanks in advance,
Martijn
--
My reply-to address is intentionally set to /dev/null,
you can reach me at mlievaart at orion in nl




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Martijn Lievaart wrote:
> Jamie Hamilton wrote in message <773gk4$5m7$1@news1.Radix.Net>...
> >
> >ndMatrix ndMatrix::operator*(const ndMatrix & matrix) const
> >{
> >    return ndMatrix(*this, matrix);
> >}
[...]
> >But the upside is that you won't get the extra copying in any
> >decent optimizing compiler.
> >
>
> I was under the impression that the standard disallowed this
> optimization
> now (unnamed returnvalue optimization), although it used to be a common
> optimization (cfront). Instead the compiler is now allowed to optimize
> when
> there is a named variabele (named returnvalue optimization).
>
> Am I correct or is Jamie correct?
>
> Thanks in advance,
> Martijn

It appears that you are correct, and the returned
object must have a name:

from 12.8 [class.copy]

For a function call with a class return type, if the
expression in the return statement is the name of a
local object, and the cv-unqualified type of the local
object is the same as the function return type, an
implementation is permitted to omit creating the
temporary object to hold the function return value,
even if the class copy constructor or destructor has
side effects.  In these cases, the object is destroyed
at the later of times when the original and the copy
would have been destroyed without the optimization.

Jim
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Gewin wrote in message <369939D1.459B1CB2@worldnet.att.net>...
>Martijn Lievaart wrote:


>from 12.8 [class.copy]
>
>For a function call with a class return type, if the
>expression in the return statement is the name of a
>local object, and the cv-unqualified type of the local
>object is the same as the function return type, an
>implementation is permitted to omit creating the
>temporary object to hold the function return value,
>even if the class copy constructor or destructor has
>side effects.  In these cases, the object is destroyed
>at the later of times when the original and the copy
>would have been destroyed without the optimization.
>


Does this forbid optimization in the unnamed case or
merely make it easier in the named case? It doesn't seem
to say anything about what happens when the copy constructor
and destructor don't have side effects.

I may well be out of date here, but it certainly seems
like the unnamed case would be easier to
implement than the named case. I can't see why
you would permit the named and not the unnamed.
Please correct this impression if it's wrong.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Jamie Hamilton" <jhamilton@Radix.Net> writes:

[...]

>
> I may well be out of date here, but it certainly seems like the
> unnamed case would be easier to implement than the named case. I can't
> see why you would permit the named and not the unnamed.  Please
> correct this impression if it's wrong.

Actually it appears from my experience that unnamed return value
optimization seems to be easier to implement than the NRVO.
And the Standard explicitly does allow the URVO through the same
paragraph which allows the NRVO.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 11 Jan 1999 23:24:15 GMT, Jamie Hamilton <jhamilton@Radix.Net> wrote:
>Jim Gewin wrote in message <369939D1.459B1CB2@worldnet.att.net>...

>>from 12.8 [class.copy]
>>
>>For a function call with a class return type, if the
>>expression in the return statement is the name of a
>>local object, and the cv-unqualified type of the local
>>object is the same as the function return type, an
>>implementation is permitted to omit creating the
>>temporary object to hold the function return value,
>>even if the class copy constructor or destructor has
>>side effects.  In these cases, the object is destroyed
>>at the later of times when the original and the copy
>>would have been destroyed without the optimization.

>Does this forbid optimization in the unnamed case or
>merely make it easier in the named case? It doesn't seem
>to say anything about what happens when the copy constructor
>and destructor don't have side effects.

Jim Gewin <jgewin@worldnet.att.net> writes:


[...]

>
> It appears that you are correct, and the returned object must have a
> name:
>
> from 12.8 [class.copy]
>
> For a function call with a class return type, if the expression in the
> return statement is the name of a local object, and the cv-unqualified
> type of the local object is the same as the function return type, an
> implementation is permitted to omit creating the temporary object to
> hold the function return value, even if the class copy constructor or
> destructor has side effects.  In these cases, the object is destroyed
> at the later of times when the original and the copy would have been
> destroyed without the optimization.

This paragraph starts with:

 Whenever a temporary class object is copied using a copy
 constructor, and this object and the copy have the same
 cv-unqualified type, an implementation is permitted to treat
 the original and the copy as two different ways of referring
 to the same object and not perform a copy at all, even if the
 class copy constructor or destructor have side effects.

I see this as the unnamed return value optimization.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]