public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeroen Wijnhout <Jeroen.Wijnhout@kdemail.net>
To: gcc-help@gcc.gnu.org
Subject: Re: copy ctor not called
Date: Sun, 03 Jul 2005 13:44:00 -0000	[thread overview]
Message-ID: <200507031547.33672.Jeroen.Wijnhout@kdemail.net> (raw)
In-Reply-To: <5d0f609905070305263875cb57@mail.gmail.com>

On Sunday 03 July 2005 02:26 pm, Dirk Jagdmann wrote:
> The behaviour of gcc is standard compliant, since an assignment in the
> same statement as a variable declaration is always treated by the copy
> constructor. 

This is what I expected, yet the copy constructor wasn't called. The copy 
constructor call was optimized away and -fno-elide-constructors will turn off 
this optimization.

> The mentioned gcc switch 
> -fno-elide-constructors will work, but on other compilers you'll have
> the same behaviour again.

Hmm, I get the feeling that the first part of your message is not as you 
intended. 

The point is that if I make the copy constructor private, 
I get a compile error:
error: `Foo::Foo(const Foo&)' is private
Which suggests that the copy constructor should be called in statements like:

A a = 2;

So, I'm wondering what the standard actually says. If A a =2; always means
A a(2); then I don't see why you would need the copy constructor to be public.

I've found the following in the comp.lang.c++.moderated archive:

"TITLE: direct and copy initialization

UPDATE:  In the last case ("T t3 = u;") the
user-defined conversion and the T copy constructor must
both be called.  In CD2 and until the London meeting in
July 1997, the compiler was permitted to elide the copy
constructor call as long as the copy constructor could
have been called (i.e., was accessible).  Since July
1997 and in the final draft standard, the compiler may
not make this optimization to elide the copy
constructor call."

To me this says, that I -fno-elide-constructors should be the default 
behavior. Which it isn't (at least for gcc 3.3.4).

best,
Jeroen
-- 
Kile -- KDE Integrated LaTeX Environment
http://kile.sourceforge.net

  reply	other threads:[~2005-07-03 13:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-02 18:21 Jeroen Wijnhout
2005-07-02 19:17 ` Travis Spencer
2005-07-03  8:15   ` Jeroen Wijnhout
2005-07-03 12:27 ` Dirk Jagdmann
2005-07-03 13:44   ` Jeroen Wijnhout [this message]
2005-07-05 14:10     ` Eljay Love-Jensen
2005-07-07 11:45       ` Jeroen Wijnhout
2005-07-07 12:02       ` Eljay Love-Jensen
2005-07-08 18:26         ` Jeroen Wijnhout

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200507031547.33672.Jeroen.Wijnhout@kdemail.net \
    --to=jeroen.wijnhout@kdemail.net \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).