Weird return statement

[jimjim]

Hello all,

I ve come across the following code fragment and I was wondering why is the
copy ctr called on return (rather than just returning the string statement
obj.

TIA

string PublishedProduc tsRepo :: CreateStatement () const {
string statement;

statement ="SELECT DISTINCT "
"* "
"FROM "
"map";
return string(statemen t); }

[Alf P. Steinbach]

* Bob Hairgrove:

On Sun, 26 Mar 2006 18:27:14 GMT, "Tomás" <NU**@NULL.NULL > wrote:

3) A proficient programmer would probably write:

string PublishedProduc tsRepo :: CreateStatement () const
{
return
"SELECT DISTINCT "
"* "
"FROM "
"map";
}

That should be:

std::string PublishedProduc tsRepo :: CreateStatement () const
{
return std::string(
"SELECT DISTINCT "
"* "
"FROM "
"map");
}

No, you don't need the explicit constructor call, because that
constructor is not 'explicit'.

For e.g. a std::auto_ptr you would need the explicit construction.

For std::string you don't.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Roland Pibinger]

On Sun, 26 Mar 2006 22:44:05 +0200, "Alf P. Steinbach"
<al***@start.no > wrote:

* Roland Pibinger:

In general, it's not recommendable to make your code dependent on
language hacks like RVO.

But not this.

On the contrary, it's absolutely not a good idea to resort to premature
optimization (Google for "premature optimization"): it wastes programmer
time and may end up making your program less efficient rather than more.

In this case RVO is the immature optimization :-)
I don't recommend any optimization at all.

Best regards.
Roland Pibinger

[Phlip]

Bob Hairgrove wrote:

That should be:

std::string PublishedProduc tsRepo :: CreateStatement () const
{
return std::string(
"SELECT DISTINCT "
"* "
"FROM "
"map");
}

Why?

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Alf P. Steinbach]

* Phlip:

Tomás wrote:

1) The "statement" object is default constructed, and the an assignment
is performed. This is inefficent -- it should have just been a
construction:

string statement("bla bla");
The compiler is required to directly call the constructor, even if = is
used.

Tomás was referring to the assignment operator call, I think.

2) There's no point in creating that nameless temporary in the "return"
statement. It could simply be:

return statement;

I do know that Return Value Optimization could make one of the strings
inside the function become an alias for the final string outside the
function. But I don't know how aggressive that rule is.

Not very, it applies to temporaries and returning a named local
variable. But that's enough here, and what kicks in here anyway is the
"as if" rule. std::string is a class known by the compiler, and it can
optimize as it wants to, regardless of the RVO rule.

Suppose the copy
constructor for std::string had a side effect that you could count. RVO will
make one of those side effects go away. (That's why it's a permitted
optimization and defined as "lossy"; so programmers will know better than to
depend on the number of side-effects from such constructors.)

Will RVO make all of this go away?

return string(string(s tring(string(st ring(string(sta tement))))));

RVO /can/ make all of that go away, "whenever a temporary class object
is copied using a copy constructor".

Whether it will or not depends on the compiler etc.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?