jpotter@falcon.lhup.edu (John Potter) wrote in message news:<3e423856.49699843@news.earthlink.net>...
> On Thu, 6 Feb 2003 01:36:00 +0000 (UTC), witoldk@optonline.net (WitoldK)
> wrote:
>
> > > While this does mean that the copy ctor may not actually be used in
> > > every case where you might expect it to be
>
> > I'd expect it to be used for passing an object by value. Is that reasonable
> > ?
>
> Yes, if you have an object to pass.  No, if the object must be constructed
> and passed in the expression.
>
> void sink (T) { }
> void f (T t) {
>  sink(t);   // copy construct
>     sink(T()); // may copy or default construct in parameter.

My "long term" goal is: _must_ "default construct in parameter" :-)


>     }

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

witoldk wrote:
> Then it is not up to the standard to decide what copy constructors
> should and should not do.

What a curious statement! On the contrary, it is only up to the
standard to decide this. In any case, as I keep pointing out and
you keep ignoring, it is not the copy constructor which is being
elided, but the copy.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <9bed99bb.0302070617.51c8f3c3@posting.google.com>, witoldk
<witoldk@optonline.net> writes
>One of us gets it backwards (the copying part) :-)
>AFAIK every copy constructor copies by definition.
>Copy constructor defines what copying means, not the
>standard :-)

And the standard places constraints on the meanings you can use if you
expect your code to behave predictably.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:ZnpHf8GCu6Q+EwgO@robinton.demon.co.uk...
> In article <UiD0a.159017$HG.24364401@news4.srv.hcvlny.cv.net>, WitoldK
> <witoldk@optonline.net> writes
> >I thought there were no changes from C. At least I haven't found any
> >in annex C of the standard. Or have I missed where the changes are
> >spelled out?
>
> As C does not have copy ctors, pass by value in C++ IS the same as pass
> by value in C when the C++ code is also valid C code.

Are you suggesting it is undefined ( behavior :) otherwise ?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

witoldk <witoldk@optonline.net> wrote:

> kuyper@wizard.net (James Kuyper) wrote...
> > witoldk@optonline.net (witoldk) wrote...
> > > I find it difficult to interpret certain portions of the standard.
> > > Admittedly, I'm only casually familiar with it, hence my hope in ge=
tting
> > > some authoritative answers here.
> > >=20
> > > In short, the question is: why 12.8.15 does not contradict 12.2.1 ?
> > >=20
> > > To be more specific: the short discussion on comp.lang.c++.moderate=
d
> > > under "by-value arg with the default" led me to believe that frivol=
ous
> > > ambiguities are allowed by the standard C++.

> > There's no ambiguity; in fact, fully half of 12.2.1 is an explanation
> > of how the exception created by 12.8.15 fits into the general rule.
[...]
> > The implementation has the freedom to either perform or not perform o=
ne
> > copy; nothing more.

> The implementation must not have this freedom when it comes to
> passing function arguments by value.

Why not ? Do you have any specific case in mind, where "one could not
reasonably expect programs written in C++ to behave in any consistent
way" because of this rule ?

By the way: The implementation is not permitted to "ignore the copy
constructor". All it may do is elide a copy. But of course it must use
the copy constructor for any copy it does perform.

> > In the contexts where that permission exists, for
> > most ordinary copy constructors the copy that can be dropped is a
> > waste of time, which is why dropping it is permitted.

> I understand the intensions in 12.8.15 are good :) But what you are
> saying is wrong. There is no way for the standard to know what an
> ordinary constructor is. They are all the same. There is not even
> one copy constructor that is extraordinary.

Well, the primary purpose of a copy constructor is to copy. One more
restrictive view of what constitutes an 'ordinary' copy is expressed in
the CopyConstructible requirement: a copy should be equivalent to the
copied object. This requirement is a way to express value semantics and
is derived from the way values are copied in C.

In C certain copies of temporary objects can be elided, as there is no
way to detect whether the copy has taken place. The C++ standard still
allows implementations to elide such copies in those cases. It allows
eliding such copies even in the case where the implementation doesn't
know whether the copy has detectable side effects. It is a side effect
[;-)] of this, that the copy can be elided even if it is known to have
side effects.

Pass by value and return by value are designed to pass and return
objects that have value semantics. For such objects, where original
object and copy are equivalent and where the copy operations do nothing
but to copy the state of the original object to the new object eliding a
copy does no harm and is even desirable as it avoids the cost of the
copy.

If your type doesn't have value semantics, you need to be careful when
using return by value or temporary objects. In those cases  you may
encounter any of the execution sequences allowed by 12.8/15. If the
difference matters to you, you should not use temporary objects in a
context where they are copied  and  you should not return a named
object by value.

> > In the case where copies can be elided, what 12.2.1 guarantees is tha=
t
> > the semantic restrictions (such as access requirements) must be
> > respected, as if the copy had actually occurred.
>=20
> The "such as" part implies there are others. What are those?

Some examples: To copy an rvalue there must be a copy constructor that
has a 'T const &' parameter, as rvalue can't be bound to other
references. If the copy constructor is inline, it must be  defined in
this translation unit. There might be more restrictions arising from
default argument expressions, if the copy constructor has additional
parameters.
=20
> > However, that refers
> > only to the restrictions, not to the rest of the semantics of copy
> > construction. If the copy constructor has side effects (such as
> > updating a counter to keep track of how many times it had been called=
)
> > then those side effects are NOT required to be achieved.
>=20
> You could not possibly mean that :-)

It is not me, but why not  ?

> For one part most every constructor has side effects, at least
> according to the standard's view of side effects as in 1.9.7.
> If we take that for definition of side effects, then constructor
> initializing member data has side effects. Because modifying an
> object ("region of storage" according to 1.8.1) is a side effect.

I assume, that what is meant here are side effects of the copy
constructor that are not part of its primary effect of initializing the
object being constructed. But it does not really matter here: If a copy
is elided, then neither those effects nor any initialization takes
place.  Of course that is entirely appropriate, as there is no second
object to be initialized.

> Then it is not up to the standard to decide what copy constructors
> should and should not do.=20

One the one hand: who else would it be up to ?

> That is because of the very fundamental
> premise of the language: the user has the ability to _define_ a type.
> The standard could not _possibly_ know what copying of objects of
> _user_defined_ type might mean. User defines what copying of
> user defined type objects means by writing a copy constructor.
> I take what you said to mean: the standard says I should not expect
> my copy constructor to do what I've defined it to do :-)

On the other hand, the standard does hardly limit your ability to define
what copying objects of your type means and does. It does specify
certain restrictions your copy constructor must fulfill in order to be
eligible for copying rvalues or to be usable with some parts of the
standard library. But I don't see any restriction on copy constructors
in 12.8/15.

> Where am I wrong?

In 12.8/15 the standard only tells you what you can and can't expect to
happen when you use certain language constructs. When using some form of
return by value and when copy-initializing objects (including function
parameters) from temporary objects, there are multiple possible
execution sequences, that differ (only) in the number of copies
performed. You can expect one of them to happen, but it is unspecified
which one you will encounter.

Again: if that difference is a problem for you, don't do it. Use named
objects instead of temporaries. If you really want to prevent the named
return value optimization, there are ways to do that too. (From the
wording of 12.8/15 it seems that using "return (0,t);" instead of
"return t;" should be enough to force a copy.) Of course the return
value will be a temporary, so be careful not to copy it directly.

Ciao, J=F6rg

--=20
J=F6rg Barfurth                         barfurth@gmx.net
<<<<<<<<<<<<< using std::disclaimer;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer                    http://util.openoffice.org
StarOffice Configuration    # Deutsch:http://de.openoffice.org

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1044648130.618804@master.nyc.kbcfp.com...
> witoldk wrote:
> > Then it is not up to the standard to decide what copy constructors
> > should and should not do.
>
> What a curious statement! On the contrary, it is only up to the
> standard to decide this. In any case, as I keep pointing out and
> you keep ignoring, it is not the copy constructor which is being
> elided, but the copy.

Sorry, did not mean to ignore anything. I thought you said that when
arg by value has a default my c-ctor could never be invoked.
Do you need a quote ?


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1044648130.618804@master.nyc.kbcfp.com...
> witoldk wrote:
> > Then it is not up to the standard to decide what copy constructors
> > should and should not do.
>
> What a curious statement! On the contrary, it is only up to the
> standard to decide this.

I think you know what I meant.
It is up to the standard to decide the constructor must not do things like
7 = k;
but not up to the standard to decide k = 7; is inappropriate in the
constructor.


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:3fHMxrN+1AR+Ewv7@robinton.demon.co.uk...
> In article <9bed99bb.0302070617.51c8f3c3@posting.google.com>, witoldk
> <witoldk@optonline.net> writes
> >One of us gets it backwards (the copying part) :-)
> >AFAIK every copy constructor copies by definition.
> >Copy constructor defines what copying means, not the
> >standard :-)
>
> And the standard places constraints on the meanings you can use if you
> expect your code to behave predictably.

What would that be ? The meanings I can not use.
I'm sorry, can't find the time to look it up myself, since everybody seems
to
be after me lately :)


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

m.collett@auckland.ac.nz (Matthew Collett) wrote in message news:<m.collett-734479.19364807022003@lust.ihug.co.nz>...
> In article <8b42afac.0302061717.4a81c460@posting.google.com>,
>  kuyper@wizard.net (James Kuyper) wrote:
>
> > The key fact is that it's implementation-defined whether the copy
> > constructor is invoked, in the situations described by 12.8.15.
>
> Do you really mean 'implementation-defined'?  I would have expected
> 'unspecified'.  IOW, is the implementation really required to document
> its choice here?

You're right, of course.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

witoldk@optonline.net (witoldk) wrote in message news:<9bed99bb.0302070612.a63f7a5@posting.google.com>...
> kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0302061717.4a81c460@posting.google.com>...
...
> > There's no ambiguity; in fact, fully half of 12.2.1 is an explanation
> > of how the exception created by 12.8.15 fits into the general rule.
> > The key fact is that it's implementation-defined whether the copy

My mistake. I should have said "unspecified".

> > constructor is invoked, in the situations described by 12.8.15.
> > Correctly written programs should therefore not have their correctness
> > depend upon how that uncertainty is resolved. This is not, as you
> > imply, permission for an implementation to do whatever it wants.
> > The implementation has the freedom to either perform or not perform one
> > copy; nothing more.
>
> The implementation must not have this freedom when it comes to
> passing function arguments by value.

You can assert this, if you wish, but I don't see any obvious reason
why that's a problem. Most copy constructors don't have side effects.
Some do, such as the ones for reference-counted smart pointers, or
objects that get registered upon creation, but those side effects are
precisely intended to keep track of the number of copies that exist.
The call to the copy constructor can be elided, precise because the
unnecessary temporary is NOT created. Therefore, 12.8.15 causes no
problems for such classes. The only code I could imagine breaking as a
result is code with copy constructors instrumented to keep track of
how often they're called, which has an expectation written into of
what that count should be that is based upon ignoring 12.8.15, and
which arbitrarily chooses to fail solely because that faulty
expectation isn't met.

Can you provide an example of a real problem whose solution is made
unnecessarily complicated (or even impossible) to design because of
the freedom allowed by 12.8.15?

> > In the contexts where that permission exists, for
> > most ordinary copy constructors the copy that can be dropped is a
> > waste of time, which is why dropping it is permitted.
> >
>
> I understand the intensions in 12.8.15 are good :) But what you are
> saying is wrong. There is no way for the standard to know what an
> ordinary constructor is. They are all the same. There is not even
> one copy constructor that is extraordinary.

The standard doesn't know anything. It's a document, not a person. So
I'm not sure what you mean by that. I literally have no idea what
objection it is that you're trying to express. You might try rewording
it.

When I referred to "ordinary constructors", I meant nothing more or
less than the fact that constructors for which 12.8.15 would actually
cause a problem are quite rare.

> > In the case where copies can be elided, what 12.2.1 guarantees is that
> > the semantic restrictions (such as access requirements) must be
> > respected, as if the copy had actually occurred.
>
> The "such as" part implies there are others. What are those?

12.1p11 and 12, for instance. Since special member functions are
member functions, 9.3p2,3,4,5, and 8 apply. Since they are class
members, 9.2p1,6,8,9, and 13 apply. I could go on, but that should be
enough.

> > However, that refers
> > only to the restrictions, not to the rest of the semantics of copy
> > construction. If the copy constructor has side effects (such as
> > updating a counter to keep track of how many times it had been called)
> > then those side effects are NOT required to be achieved.
>
> You could not possibly mean that :-)

Well, I do.

> For one part most every constructor has side effects, at least
> according to the standard's view of side effects as in 1.9.7.
> If we take that for definition of side effects, then constructor
> initializing member data has side effects. Because modifying an
> object ("region of storage" according to 1.8.1) is a side effect.

In this context, I wasn't using the term "side-effects" in that
restricted a sense. What I meant was any effect other than actually
setting up the values stored in the object. Examples would include any
change to the value of any object other than the one under
construction, or execution of any I/O function.


> Then it is not up to the standard to decide what copy constructors
> should and should not do. ...

Correct.

> ... That is because of the very fundamental
> premise of the language: the user has the ability to _define_ a type.
> The standard could not _possibly_ know what copying of objects of
> _user_defined_ type might mean. User defines what copying of
> user defined type objects means by writing a copy constructor.
> I take what you said to mean: the standard says I should not expect
> my copy constructor to do what I've defined it to do :-)

That is very much NOT what I'm saying. You get to decide precisely
what a copy constructor does when it is called. You do NOT get to
decide when it gets called, that's entirely the responsibility of the
standard.. If you want the copy constructor for 'b' invoked when you
write

        int c = 3;

you're out of luck. The standard says that 'b's copy constructor isn't
called because of that line of code (an optimizer might move a copy
constructor call to that point, but that's a different issue). If you
want the copy constructor for 'b' to NOT be called when you write:

        B b(a);

then you're also out of luck. And if you want the copy constructor to
be invoked exactly two times under the circumstances where 12.8.15
allows (but does not require) that one of the calls to be elided,
you're also out of luck. And since 12.8.15 does exist, if you've
written code that breaks as a result, it's not valid portable C++
code.

> Where am I wrong?

Well, the biggest thing you've done wrong is failing to show how
writing code that will work correctly despite 12.8.15, is a serious
difficulty.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Randy Maddox" <rmaddox@isicns.com> wrote in message
news:8c8b368d.0302050634.39d80f45@posting.google.com...
> witoldk@optonline.net (witoldk) wrote in message
news:<9bed99bb.0302040905.3c9e0661@posting.google.com>...
> > I find it difficult to interpret certain portions of the standard.
> > Admittedly, I'm only casually familiar with it, hence my hope in getting
> > some authoritative answers here.
> >
> > In short, the question is: why 12.8.15 does not contradict 12.2.1 ?
> >
> > To be more specific: the short discussion on comp.lang.c++.moderated
under
> > "by-value arg with the default" led me to believe that frivolous
ambiguities
> > are allowed by the standard C++.
> > I understand this is quite a heavy statement and it is more than likely
that
> > it is my ignorance that leads me to believe that. Yet, I will be quite
happy
> > to be proven ignorant in this matter (since it looks rather disturbing
:-).
> > Apparently 12.8.15 allows the copy constructor to be ignored by the
compiler
> > [12.8.15 quote]
> >  even if the class copy constructor or destructor have side effects.
> > [quote]
> > when returning class object by value (as well as when passing class
object
> > by value).
> > If true, one could not reasonably expect programs written in C++ to
behave
> > in any consistent way (when class c-ctor or dtor has side effects and
one
> > decides to pass/return objects of such class by value, that is :-).
> > Please help me understand what is it that I am missing here.
> >
>
> I think that what you may be missing are two concerns in the design of
> C++.  First, C++ is intended to be efficient, which is certainly a
> valid requirement for a systems programming language.  Second is the
> fact that allowing the compiler to elide copies not only allows the
> return value optimization, it is also consistent with the C++
> philosophy of only paying for what you use.

I did not think I missed these :-)


> While this does mean that the copy ctor may not actually be used in
> every case where you might expect it to be

I'd expect it to be used for passing an object by value. Is that reasonable
?


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1044387362.41332@master.nyc.kbcfp.com...
> witoldk wrote:
> > Apparently 12.8.15 allows the copy constructor to be ignored by the
compiler
> > If true, one could not reasonably expect programs written in C++ to
behave
> > in any consistent way (when class c-ctor or dtor has side effects and
one
> > decides to pass/return objects of such class by value, that is :-).
> > Please help me understand what is it that I am missing here.
>
> You are missing that the copy constructor is not being ignored.
> It's just that in limited circumstances, when the straight
> semantics of the language require a copy from "here" to "there",
> the compiler is allowed to combine "here" and "there" into a
> single location and thus avoid the copy (not the copy constructor).

I'm not sure I understand how would that not amount to ignoring a copy
constructor.
In particular, when passing things by value, and when given arg also has a
default
(say vector's resize's second arg: T t = T()) would not the compiler be
allowed
to combine "here" - the T() with the "there" the stack and in effect default
construct
T on the stack completely ignoring the c-ctor of T ?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jm@bourguet.org (Jean-Marc Bourguet) wrote in message
news:<pxblm0u1vcr.fsf@news.bourguet.org>...
> kanze@gabi-soft.de (James Kanze) writes:

> > > [12.8.15 quote]
> > >  even if the class copy constructor or destructor have side effects.
> > > [quote]
> > > when returning class object by value (as well as when passing
> > > class object by value).  If true, one could not reasonably expect
> > > programs written in C++ to behave in any consistent way (when
> > > class c-ctor or dtor has side effects and one decides to
> > > pass/return objects of such class by value, that is :-).  Please
> > > help me understand what is it that I am missing here.

> > Nothing.  A well designed copy constructor shouldn't have side
> > effects.

> Isn't using allocating memory a side effect?

For certain definitions of side effects.  The standard doesn't consider
it part of the observable behavior which must be respected, see    1.9/6.

The argument is perhaps weakened by the fact that the user can replace
the allocation functions, and his replacement functions might invoke IO,
which is observable behavior.  However, the standard very definitly
requires the replacement function to implement the semantics of the
original function; if those semantics don't involve externally
observable behavior (and those of the allocation functions don't), then
the user supplied function may not either.  (There is also the point
that the standard only forbids two functions, malloc and free, from
using operator new, so calling any other standard function in a user
supplied operator new is likely to invoke endless recursion.)

> I agree, 12.8.15 should not change the meaning of well designed C++
> programs, even if they are designed by people ignoring that part of
> C++.

What part of C++?  The key here phrase here is "well designed".
Suppressing an unnecessary copy will not change the behavior of a well
designed program (except with regards to execution time).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

witoldk@optonline.net (WitoldK) wrote in message news:<nLi0a.131105$HG.20610612@news4.srv.hcvlny.cv.net>...
> "Randy Maddox" <rmaddox@isicns.com> wrote in message
> news:8c8b368d.0302050634.39d80f45@posting.google.com...
> > witoldk@optonline.net (witoldk) wrote in message
>  news:<9bed99bb.0302040905.3c9e0661@posting.google.com>...
>
> > While this does mean that the copy ctor may not actually be used in
> > every case where you might expect it to be
>
> I'd expect it to be used for passing an object by value. Is that reasonable
> ?
>

While that certainly seems reasonable, it is also conceivable that in
some cases the copy ctor may be called fewer times than expected.  For
example, what about the following code snippet?

  void foo(T value)
  {
    T  localValue(value);

    ...
  }

It would seem that calling foo() would result in two calls to the T
copy ctor, one to copy from the caller's T object into the value
parameter, and one to copy that copy into foo()'s localValue.
However, if there is no other use of the value parameter in foo(),
then it is also conceivable that the compiler might elide the first
copy and simply copy from the caller's original T object into foo()'s
localValue.  Obviously this is a contrived example and the more common
case where the compiler could elide a copy would be in return by
value.

Randy.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 6 Feb 2003 01:36:00 +0000 (UTC), witoldk@optonline.net (WitoldK)
wrote:

> > While this does mean that the copy ctor may not actually be used in
> > every case where you might expect it to be

> I'd expect it to be used for passing an object by value. Is that reasonable
> ?

Yes, if you have an object to pass.  No, if the object must be constructed
and passed in the expression.

void sink (T) { }
void f (T t) {
 sink(t);   // copy construct
    sink(T()); // may copy or default construct in parameter.
    }

John

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

WitoldK wrote:
> In particular, when passing things by value,
 > and when given arg also has a default
> (say vector's resize's second arg: T t = T())
 > would not the compiler be> allowed to combine
 > "here" - the T() with the "there" the stack
 > and in effect default construct T on the stack
 > completely ignoring the c-ctor of T ?

Yes, it can do exactly that. Copy constructors
are supposed to copy, and the standard gives
compilers the liberty to avoid copying in some
cases.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 6 Feb 2003 15:20:37 +0000 (UTC), rmaddox@isicns.com (Randy Maddox)
wrote:

> While that certainly seems reasonable, it is also conceivable that in
> some cases the copy ctor may be called fewer times than expected.  For
> example, what about the following code snippet?

>   void foo(T value)
>   {
>     T  localValue(value);

>     ...
>   }

> It would seem that calling foo() would result in two calls to the T
> copy ctor, one to copy from the caller's T object into the value
> parameter, and one to copy that copy into foo()'s localValue.

Whatever might happen on the caller side is beyond the given code.  That
is the part that concerns him.

> However, if there is no other use of the value parameter in foo(),
> then it is also conceivable that the compiler might elide the first
> copy and simply copy from the caller's original T object into foo()'s
> localValue.

That would require use of the as-if rule.  There is nothing else in the
standard to allow that.  Both value and localValue are named objects.
There is no temporary involved to remove.

> Obviously this is a contrived example and the more common
> case where the compiler could elide a copy would be in return by
> value.

Not really.  The construct by value optimization is more common than
the NRVO.  The simple return T(t) is the same as T t(f()) on the
caller side.

John

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

rmaddox@isicns.com (Randy Maddox) wrote in message news:<8c8b368d.0302060625.18d34f84@posting.google.com>...
> witoldk@optonline.net (WitoldK) wrote in message news:<nLi0a.131105$HG.20610612@news4.srv.hcvlny.cv.net>...
> > "Randy Maddox" <rmaddox@isicns.com> wrote in message
> > news:8c8b368d.0302050634.39d80f45@posting.google.com...
> > > witoldk@optonline.net (witoldk) wrote in message
> >  news:<9bed99bb.0302040905.3c9e0661@posting.google.com>...
> >
> > > While this does mean that the copy ctor may not actually be used in
> > > every case where you might expect it to be
> >
> > I'd expect it to be used for passing an object by value. Is that reasonable
> > ?
> >
>
> While that certainly seems reasonable, it is also conceivable that in
> some cases the copy ctor may be called fewer times than expected.  For
> example, what about the following code snippet?
>
>   void foo(T value)
>   {
>     T  localValue(value);
>
>     ...
>   }
>
> It would seem that calling foo() would result in two calls to the T
> copy ctor, one to copy from the caller's T object into the value
> parameter, and one to copy that copy into foo()'s localValue.
> However, if there is no other use of the value parameter in foo(),
> then it is also conceivable that the compiler might elide the first
> copy and simply copy from the caller's original T object into foo()'s
> localValue.

Could not agree more. This is the place for RVO
But RVO should be kept away from calling foo, because it might change the
meaning of pass by value.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0302060228.72a40326@posting.google.com...
> jm@bourguet.org (Jean-Marc Bourguet) wrote in message
> news:<pxblm0u1vcr.fsf@news.bourguet.org>...
> > kanze@gabi-soft.de (James Kanze) writes:
>
> > > > [12.8.15 quote]
> > > >  even if the class copy constructor or destructor have side effec=
ts.
> > > > [quote]
> > > > when returning class object by value (as well as when passing
> > > > class object by value).  If true, one could not reasonably expect
> > > > programs written in C++ to behave in any consistent way (when
> > > > class c-ctor or dtor has side effects and one decides to
> > > > pass/return objects of such class by value, that is :-).  Please
> > > > help me understand what is it that I am missing here.
>
> > > Nothing.  A well designed copy constructor shouldn't have side
> > > effects.
>
> > Isn't using allocating memory a side effect?
>
> For certain definitions of side effects.  The standard doesn't consider
> it part of the observable behavior which must be respected, see =A71.9/=
6.
>
> The argument is perhaps weakened by the fact that the user can replace
> the allocation functions, and his replacement functions might invoke IO=
,
> which is observable behavior.  However, the standard very definitly
> requires the replacement function to implement the semantics of the
> original function; if those semantics don't involve externally
> observable behavior (and those of the allocation functions don't), then
> the user supplied function may not either.  (There is also the point
> that the standard only forbids two functions, malloc and free, from
> using operator new, so calling any other standard function in a user
> supplied operator new is likely to invoke endless recursion.)
>
> > I agree, 12.8.15 should not change the meaning of well designed C++
> > programs, even if they are designed by people ignoring that part of
> > C++.
>
> What part of C++?  The key here phrase here is "well designed".
> Suppressing an unnecessary copy will not change the behavior of a well
> designed program (except with regards to execution time).
>

I think the key phrase is "unnecessary".
As of now I think compilers are allowed to deem way to many copies
unnecessary.
My interest in the subject is quite narrow. I'd like to know how
pass-by-value is defined in C++.
I thought there were no changes from C. At least I haven't found any
in annex C of the standard. Or have I missed where the changes are
spelled out?


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

witoldk@optonline.net (witoldk) wrote in message news:<9bed99bb.0302040905.3c9e0661@posting.google.com>...
> I find it difficult to interpret certain portions of the standard.
> Admittedly, I'm only casually familiar with it, hence my hope in getting
> some authoritative answers here.
>
> In short, the question is: why 12.8.15 does not contradict 12.2.1 ?
>
> To be more specific: the short discussion on comp.lang.c++.moderated under
> "by-value arg with the default" led me to believe that frivolous ambiguities
> are allowed by the standard C++.
> I understand this is quite a heavy statement and it is more than likely that
> it is my ignorance that leads me to believe that. Yet, I will be quite happy
> to be proven ignorant in this matter (since it looks rather disturbing :-).
> Apparently 12.8.15 allows the copy constructor to be ignored by the compiler
> [12.8.15 quote]
>  even if the class copy constructor or destructor have side effects.
> [quote]
> when returning class object by value (as well as when passing class object
> by value).
> If true, one could not reasonably expect programs written in C++ to behave
> in any consistent way (when class c-ctor or dtor has side effects and one
> decides to pass/return objects of such class by value, that is :-).
> Please help me understand what is it that I am missing here.


There's no ambiguity; in fact, fully half of 12.2.1 is an explanation
of how the exception created by 12.8.15 fits into the general rule.
The key fact is that it's implementation-defined whether the copy
constructor is invoked, in the situations described by 12.8.15.
Correctly written programs should therefore not have their correctness
depend upon how that uncertainty is resolved. This is not, as you
imply, permission for an implementation to do whatever it wants. The
implementation has the freedom to either perform or not perform one
copy; nothing more. In the contexts where that permission exists, for
most ordinary copy constructors the copy that can be dropped is a
waste of time, which is why dropping it is permitted.


In the case where copies can be elided, what 12.2.1 guarantees is that
the semantic restrictions (such as access requirements) must be
respected, as if the copy had actually occurred. However, that refers
only to the restrictions, not to the rest of the semantics of copy
construction. If the copy constructor has side effects (such as
updating a counter to keep track of how many times it had been called)
then those side effects are NOT required to be achieved.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

[to the moderator: I though I had already answered, but got no
aknowledge of the robot, so this is a resend]

> jm@bourguet.org (Jean-Marc Bourguet) wrote in message
> news:<pxblm0u1vcr.fsf@news.bourguet.org>...
> > kanze@gabi-soft.de (James Kanze) writes:
>=20
> > > > [12.8.15 quote]
> > > >  even if the class copy constructor or destructor have side effec=
ts.
> > > > [quote]
> > > > when returning class object by value (as well as when passing
> > > > class object by value).  If true, one could not reasonably expect
> > > > programs written in C++ to behave in any consistent way (when
> > > > class c-ctor or dtor has side effects and one decides to
> > > > pass/return objects of such class by value, that is :-).  Please
> > > > help me understand what is it that I am missing here.
>=20
> > > Nothing.  A well designed copy constructor shouldn't have side
> > > effects.
>=20
> > Isn't using allocating memory a side effect?
>=20
> For certain definitions of side effects.  The standard doesn't consider
> it part of the observable behavior which must be respected, see =A71.9/=
6.
> The argument is perhaps weakened by the fact that the user can replace
> the allocation functions, and his replacement functions might invoke IO=
,
> which is observable behavior.
[...]

Changing the number or the order of allocation can lead to observable
behaviour.  For example by the use of std::less<> on the returned
pointers.  In the case of user defined allocators, it is even possible
to get a portable observable behaviour.

[...]=20
> > I agree, 12.8.15 should not change the meaning of well designed C++
> > programs, even if they are designed by people ignoring that part of
> > C++.
>=20
> What part of C++? =20

12.8.15 obviously.

> The key here phrase here is "well designed".  Suppressing an
> unnecessary copy will not change the behavior of a well designed
> program (except with regards to execution time).

It should not change the specified part of the result of running the
program.  It can have some side effects such as changing the order of
output (again the use of std::less<>, note that I usually define my
ordering when it is used in output context: it is far easier to
automate regression tests when the output is constant accross
platform, allocator used and optimization level).

--=20
Jean-Marc

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<1044547122.900653@master.nyc.kbcfp.com>...
> WitoldK wrote:
> > In particular, when passing things by value,
>  > and when given arg also has a default
> > (say vector's resize's second arg: T t = T())
>  > would not the compiler be> allowed to combine
>  > "here" - the T() with the "there" the stack
>  > and in effect default construct T on the stack
>  > completely ignoring the c-ctor of T ?
>
> Yes, it can do exactly that. Copy constructors
> are supposed to copy, and the standard gives
> compilers the liberty to avoid copying in some
> cases.

One of us gets it backwards (the copying part) :-)
AFAIK every copy constructor copies by definition.
Copy constructor defines what copying means, not the
standard :-)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <8b42afac.0302061717.4a81c460@posting.google.com>,
 kuyper@wizard.net (James Kuyper) wrote:

> The key fact is that it's implementation-defined whether the copy
> constructor is invoked, in the situations described by 12.8.15.

Do you really mean 'implementation-defined'?  I would have expected
'unspecified'.  IOW, is the implementation really required to document
its choice here?

Best wishes,
Matthew Collett

--
Those who assert that the mathematical sciences have nothing to say
about the good or the beautiful are mistaken.          -- Aristotle

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <UiD0a.159017$HG.24364401@news4.srv.hcvlny.cv.net>, WitoldK
<witoldk@optonline.net> writes
>I thought there were no changes from C. At least I haven't found any
>in annex C of the standard. Or have I missed where the changes are
>spelled out?

As C does not have copy ctors, pass by value in C++ IS the same as pass
by value in C when the C++ code is also valid C code.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0302061717.4a81c460@posting.google.com>...
> witoldk@optonline.net (witoldk) wrote in message news:<9bed99bb.0302040905.3c9e0661@posting.google.com>...
> > I find it difficult to interpret certain portions of the standard.
> > Admittedly, I'm only casually familiar with it, hence my hope in getting
> > some authoritative answers here.
> >
> > In short, the question is: why 12.8.15 does not contradict 12.2.1 ?
> >
> > To be more specific: the short discussion on comp.lang.c++.moderated under
> > "by-value arg with the default" led me to believe that frivolous ambiguities
> > are allowed by the standard C++.
> > I understand this is quite a heavy statement and it is more than likely that
> > it is my ignorance that leads me to believe that. Yet, I will be quite happy
> > to be proven ignorant in this matter (since it looks rather disturbing :-).
> > Apparently 12.8.15 allows the copy constructor to be ignored by the compiler
> > [12.8.15 quote]
> >  even if the class copy constructor or destructor have side effects.
> > [quote]
> > when returning class object by value (as well as when passing class object
> > by value).
> > If true, one could not reasonably expect programs written in C++ to behave
> > in any consistent way (when class c-ctor or dtor has side effects and one
> > decides to pass/return objects of such class by value, that is :-).
> > Please help me understand what is it that I am missing here.
>
>
> There's no ambiguity; in fact, fully half of 12.2.1 is an explanation
> of how the exception created by 12.8.15 fits into the general rule.
> The key fact is that it's implementation-defined whether the copy
> constructor is invoked, in the situations described by 12.8.15.
> Correctly written programs should therefore not have their correctness
> depend upon how that uncertainty is resolved. This is not, as you
> imply, permission for an implementation to do whatever it wants.
> The implementation has the freedom to either perform or not perform one
> copy; nothing more.

The implementation must not have this freedom when it comes to
passing function arguments by value.

> In the contexts where that permission exists, for
> most ordinary copy constructors the copy that can be dropped is a
> waste of time, which is why dropping it is permitted.
>

I understand the intensions in 12.8.15 are good :) But what you are
saying is wrong. There is no way for the standard to know what an
ordinary constructor is. They are all the same. There is not even
one copy constructor that is extraordinary.

>
> In the case where copies can be elided, what 12.2.1 guarantees is that
> the semantic restrictions (such as access requirements) must be
> respected, as if the copy had actually occurred.

The "such as" part implies there are others. What are those?

> However, that refers
> only to the restrictions, not to the rest of the semantics of copy
> construction. If the copy constructor has side effects (such as
> updating a counter to keep track of how many times it had been called)
> then those side effects are NOT required to be achieved.

You could not possibly mean that :-)
For one part most every constructor has side effects, at least
according to the standard's view of side effects as in 1.9.7.
If we take that for definition of side effects, then constructor
initializing member data has side effects. Because modifying an
object ("region of storage" according to 1.8.1) is a side effect.
Then it is not up to the standard to decide what copy constructors
should and should not do. That is because of the very fundamental
premise of the language: the user has the ability to _define_ a type.
The standard could not _possibly_ know what copying of objects of
_user_defined_ type might mean. User defines what copying of
user defined type objects means by writing a copy constructor.
I take what you said to mean: the standard says I should not expect
my copy constructor to do what I've defined it to do :-)

Where am I wrong?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0302050128.36880ebf@posting.google.com...
> witoldk@optonline.net (witoldk) wrote in message
> news:<9bed99bb.0302040905.3c9e0661@posting.google.com>...
> > I find it difficult to interpret certain portions of the standard.
> > Admittedly, I'm only casually familiar with it, hence my hope in
> > getting some authoritative answers here.
>
> > In short, the question is: why 12.8.15 does not contradict 12.2.1 ?
>
> > To be more specific: the short discussion on comp.lang.c++.moderated
> > under "by-value arg with the default" led me to believe that frivolous
> > ambiguities are allowed by the standard C++.
>
> I'm not sure what you mean be "frivolous" ambiguities, but ambiguities
> are not rare in standard C++.

By frivolous I mean that the particular ambiguity I'm talking about has no
good
enough reason (or I'm missing it,).

> > [12.8.15 quote]
> >  even if the class copy constructor or destructor have side effects.
> > [quote]
> > when returning class object by value (as well as when passing class
> > object by value
[snip]
> Nothing.  A well designed copy constructor shouldn't have side effects.
> If a copy constructor does have side effects, the behavior of the
> program is unspecified (but only with regards to the frequency of these
> side effects).
>

I must be missing something :-)


1.9.7 reads:
"
Accessing an object designated by a volatile lvalue (3.10), modifying an
object, calling a library I/O function, or calling a function that does any
of
those operations are all side effects, which are changes in the state of the
execution environment.
"
I am assuming here the "object" being "a region of storage" as in 1.8.1.
If side effects are those in 1.9.7, then the constructor initializing member
data has
side effects. Which constructors then, other than the ones for "empty"
class, would
not have side effects? More to the topic: why the 12.8.15 part quoted in the
OP does
not contradict the 12.2.1 in the part where it reads:
"
Even when the creation of the temporary object is avoided (12.8), all the
semantic
restrictions must be respected as if the temporary object was
created.[Example: even
if the copy constructor is not called, all the semantic restrictions, such
as accessibility
(clause 11), shall be satisfied. ]
"
What would these semantic restrictions be ? Note the "such as" implying
there are other
in addition to "accessibility".
Note: "all the semantic restrictions must be respected as if the temporary
object was
created"
I take "semantic" to mean "meaning". I would then translate the above
roughly into
English as: when copy is not created then there is supposed to be no way to
tell it was
not. I might be wrong right here (in the translation), but I'd expect that
to guarantee, that
when (inside a function body) the arg is passed by value I should not be
able to tell it
from the one created by a c-ctor. Does not 12.2.1 guarantee that?
Does not 12.8.15 let the compiler skip my c-ctor altogether when passing
things by value?
Here must be the thing that I'm missing, as for me the answer to both
questions is yes.
Hence the contradiction. Where am I wrong?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I find it difficult to interpret certain portions of the standard.
Admittedly, I'm only casually familiar with it, hence my hope in getting
some authoritative answers here.

In short, the question is: why 12.8.15 does not contradict 12.2.1 ?

To be more specific: the short discussion on comp.lang.c++.moderated under
"by-value arg with the default" led me to believe that frivolous ambiguities
are allowed by the standard C++.
I understand this is quite a heavy statement and it is more than likely that
it is my ignorance that leads me to believe that. Yet, I will be quite happy
to be proven ignorant in this matter (since it looks rather disturbing :-).
Apparently 12.8.15 allows the copy constructor to be ignored by the compiler
[12.8.15 quote]
 even if the class copy constructor or destructor have side effects.
[quote]
when returning class object by value (as well as when passing class object
by value).
If true, one could not reasonably expect programs written in C++ to behave
in any consistent way (when class c-ctor or dtor has side effects and one
decides to pass/return objects of such class by value, that is :-).
Please help me understand what is it that I am missing here.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

witoldk@optonline.net (witoldk) wrote in message
news:<9bed99bb.0302040905.3c9e0661@posting.google.com>...
> I find it difficult to interpret certain portions of the standard.
> Admittedly, I'm only casually familiar with it, hence my hope in
> getting some authoritative answers here.

> In short, the question is: why 12.8.15 does not contradict 12.2.1 ?

> To be more specific: the short discussion on comp.lang.c++.moderated
> under "by-value arg with the default" led me to believe that frivolous
> ambiguities are allowed by the standard C++.

I'm not sure what you mean be "frivolous" ambiguities, but ambiguities
are not rare in standard C++.

> I understand this is quite a heavy statement and it is more than
> likely that it is my ignorance that leads me to believe that. Yet, I
> will be quite happy to be proven ignorant in this matter (since it
> looks rather disturbing :-).  Apparently 12.8.15 allows the copy
> constructor to be ignored by the compiler

The wording is complex, but the intention is, I believe, that for
purposes of optimization, the compiler can consider that the copy
constructor has no visible side effects.

> [12.8.15 quote]
>  even if the class copy constructor or destructor have side effects.
> [quote]
> when returning class object by value (as well as when passing class
> object by value).  If true, one could not reasonably expect programs
> written in C++ to behave in any consistent way (when class c-ctor or
> dtor has side effects and one decides to pass/return objects of such
> class by value, that is :-).  Please help me understand what is it
> that I am missing here.

Nothing.  A well designed copy constructor shouldn't have side effects.
If a copy constructor does have side effects, the behavior of the
program is unspecified (but only with regards to the frequency of these
side effects).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

witoldk wrote:
> Apparently 12.8.15 allows the copy constructor to be ignored by the compiler
> If true, one could not reasonably expect programs written in C++ to behave
> in any consistent way (when class c-ctor or dtor has side effects and one
> decides to pass/return objects of such class by value, that is :-).
> Please help me understand what is it that I am missing here.

You are missing that the copy constructor is not being ignored.
It's just that in limited circumstances, when the straight
semantics of the language require a copy from "here" to "there",
the compiler is allowed to combine "here" and "there" into a
single location and thus avoid the copy (not the copy constructor).

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) writes:

> > [12.8.15 quote]
> >  even if the class copy constructor or destructor have side effects.
> > [quote]
> > when returning class object by value (as well as when passing class
> > object by value).  If true, one could not reasonably expect programs
> > written in C++ to behave in any consistent way (when class c-ctor or
> > dtor has side effects and one decides to pass/return objects of such
> > class by value, that is :-).  Please help me understand what is it
> > that I am missing here.
>
> Nothing.  A well designed copy constructor shouldn't have side
> effects.

Isn't using allocating memory a side effect?

I agree, 12.8.15 should not change the meaning of well designed C++
programs, even if they are designed by people ignoring that part of
C++.

--
Jean-Marc

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

witoldk@optonline.net (witoldk) wrote in message news:<9bed99bb.0302040905.3c9e0661@posting.google.com>...
> I find it difficult to interpret certain portions of the standard.
> Admittedly, I'm only casually familiar with it, hence my hope in getting
> some authoritative answers here.
>
> In short, the question is: why 12.8.15 does not contradict 12.2.1 ?
>
> To be more specific: the short discussion on comp.lang.c++.moderated under
> "by-value arg with the default" led me to believe that frivolous ambiguities
> are allowed by the standard C++.
> I understand this is quite a heavy statement and it is more than likely that
> it is my ignorance that leads me to believe that. Yet, I will be quite happy
> to be proven ignorant in this matter (since it looks rather disturbing :-).
> Apparently 12.8.15 allows the copy constructor to be ignored by the compiler
> [12.8.15 quote]
>  even if the class copy constructor or destructor have side effects.
> [quote]
> when returning class object by value (as well as when passing class object
> by value).
> If true, one could not reasonably expect programs written in C++ to behave
> in any consistent way (when class c-ctor or dtor has side effects and one
> decides to pass/return objects of such class by value, that is :-).
> Please help me understand what is it that I am missing here.
>

I think that what you may be missing are two concerns in the design of
C++.  First, C++ is intended to be efficient, which is certainly a
valid requirement for a systems programming language.  Second is the
fact that allowing the compiler to elide copies not only allows the
return value optimization, it is also consistent with the C++
philosophy of only paying for what you use.  If the compiler can
determine that a copy is not actually necessary, then you do not have
to pay for that copy.

While this does mean that the copy ctor may not actually be used in
every case where you might expect it to be, I hardly think this counts
as "frivolous ambiguities", nor does it imply inconsistent behavior.
It is simply a matter of not performing unecessary, and possibly
expensive, copying.

Randy.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]