Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Joel Brobecker <brobecker@adacore.com>,
	Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC][13/19] Target FP: Perform Ada fixed-point scaling in target format
Date: Mon, 09 Oct 2017 21:12:00 -0000	[thread overview]
Message-ID: <4543871f-9a5a-5722-b868-706948b3f3ad@simark.ca> (raw)
In-Reply-To: <20171009180952.xzg36frnnumvkrt5@adacore.com>

On 2017-10-09 02:09 PM, Joel Brobecker wrote:
>>> This is a C++ question, really. Does it make any difference if you
>>> declare the std::string first, and then only set its contents in
>>> a second statement? I can't remember the details, but it has to do
>>> with initialization vs assignment. I _really_ hope that the string
>>> class is sufficiently well designed that the two are really equivalent
>>> in practice?
>>
>> Huh.  Indeed I see worse code when doing the assignment as a separate
>> statement, at least with GCC 4.8.  I'll make sure to use initialization
>> instead wherever possible.  Thanks for pointing this out!
> 
> Let's wait for people who really know better about C++ to tell us
> whether it makes a difference. I was amazed as how careful you have
> to be when using C++ to avoid inefficiencies, but perhaps I am simply
> being paranoid in this case... That's why I tried to phrase this as
> a question.
> 

Indeed, it's preferable to use

  std::string foo = returns_string ();

than

  std::string foo;
  foo = returns_string ();

The reason being that in the second case, the default constructor (the
one with no params) is called to construct an empty string, and then that
work is scrapped because we assign a new value.  The first form constructs
the string right away with the right content.

While it's preferable to use the first one, the earth wouldn't stop spinning
if you used the second form.  In the particular case of std::string, the
default constructor is basically assigning a few fields.

Simon


  reply	other threads:[~2017-10-09 21:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05 18:21 Ulrich Weigand
2017-10-09 16:30 ` Joel Brobecker
2017-10-09 16:58   ` Ulrich Weigand
2017-10-09 18:09     ` Joel Brobecker
2017-10-09 21:12       ` Simon Marchi [this message]
2017-10-11 17:49         ` Maciej W. Rozycki

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=4543871f-9a5a-5722-b868-706948b3f3ad@simark.ca \
    --to=simark@simark.ca \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=uweigand@de.ibm.com \
    /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