Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Weird return statement

Reply
Thread Tools

Weird return statement

 
 
jimjim
Guest
Posts: n/a
 
      03-26-2006
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 PublishedProductsRepo :: CreateStatement() const {
string statement;

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


 
Reply With Quote
 
 
 
 
peter koch
Guest
Posts: n/a
 
      03-26-2006

jimjim skrev:

> 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.


The code below does not make much sense. I would have written it
simply:

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

/Peter
>
> TIA
>
> string PublishedProductsRepo :: CreateStatement() const {
> string statement;
>
> statement ="SELECT DISTINCT "
> "* "
> "FROM "
> "map";
> return string(statement); }


 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-26-2006
* jimjim:
>
> 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.
>
> string PublishedProductsRepo :: CreateStatement() const {
> string statement;
>
> statement ="SELECT DISTINCT "
> "* "
> "FROM "
> "map";
> return string(statement); }


Whether the copy constructor is called depends on your compiler and the
context of the CreateStatement call.

There is much that is unnecessary in the code, but it doesn't affect
copy constructor calls. What's important re copy constructor calls is
your compiler's optimizations.

A straightforward coding of this function is

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

Note the qualification with "std::".

If this inline function definition is in a header file, which is likely,
the lack of such qualification in the original code indicates there is a
"using namespace std;" or "using std::string;" in the header file, which
in turn indicates an incompetent programmer. In other words, if those
reasonable assumptions hold, then this is not code to learn from.
Rather, it's then code from which you can learn how to /not/ do things.

For example:

* Don't ever place "using namespace std;" in a header file.

* Don't be clever when there is no need.

* Preferentially don't name a function "ComputeCosine" when "cos" will
do: name value-producing functions for what they produce, not how.

--
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?
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      03-26-2006
In article <D_yVf.42416$(E-Mail Removed) >,
"jimjim" <(E-Mail Removed)> wrote:

> 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 PublishedProductsRepo :: CreateStatement() const {
> string statement;
>
> statement ="SELECT DISTINCT "
> "* "
> "FROM "
> "map";
> return string(statement); }


The person who wrote the code was probably worried because 'statement'
is a temporary and he wasn't sure if he was returning a temporary or
not. IE he didn't know the language very well.

Or maybe he was intentionally trying to obfuscate the code?


--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      03-26-2006
Daniel T. wrote:

> The person who wrote the code was probably worried because 'statement'
> is a temporary and he wasn't sure if he was returning a temporary or
> not. IE he didn't know the language very well.


You meant: ...probably worried because 'statement' is a local and he wasn't
sure if he was returning a reference to a local. So he returned a copy of a
temporary instead.

> Or maybe he was intentionally trying to obfuscate the code?


The OP is advised to learn better C++ than that example before further
improvements. This will probably be tricky, because if the code has many
more examples like this then some of them might rely on undefined behavior.

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


 
Reply With Quote
 
Tomás
Guest
Posts: n/a
 
      03-26-2006

> string PublishedProductsRepo :: CreateStatement() const {
> string statement;
>
> statement ="SELECT DISTINCT "
> "* "
> "FROM "
> "map";
> return string(statement); }


Looks like the coder isn't very proficient. Here's a few bad things:

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");


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

return statement;


3) A proficient programmer would probably write:

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


-Tomás
 
Reply With Quote
 
Roland Pibinger
Guest
Posts: n/a
 
      03-26-2006
On Sun, 26 Mar 2006 18:20:50 +0200, "Alf P. Steinbach"
<(E-Mail Removed)> wrote:
>Whether the copy constructor is called depends on your compiler and the
>context of the CreateStatement call.


Whether the copy constructor is elided depends on your compiler, your
used compliler switches and the context of the CreateStatement call.
In general, it's not recommendable to make your code dependent on
language hacks like RVO.

Best regards,
Roland Pibinger
 
Reply With Quote
 
Bob Hairgrove
Guest
Posts: n/a
 
      03-26-2006
On Sun, 26 Mar 2006 18:27:14 GMT, "Tomás" <(E-Mail Removed)> wrote:

>3) A proficient programmer would probably write:
>
>string PublishedProductsRepo :: CreateStatement() const
>{
> return
> "SELECT DISTINCT "
> "* "
> "FROM "
> "map";
>}


That should be:

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

--
Bob Hairgrove
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-26-2006
* Roland Pibinger:
> On Sun, 26 Mar 2006 18:20:50 +0200, "Alf P. Steinbach"
> <(E-Mail Removed)> wrote:
>> Whether the copy constructor is called depends on your compiler and the
>> context of the CreateStatement call.

>
> Whether the copy constructor is elided depends on your compiler, your
> used compliler switches and the context of the CreateStatement call.


Yes, I think you have understood that correctly.


> 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.

--
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?
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      03-26-2006
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.

> 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. 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(string(string(string(string(statemen t))))));

> 3) A proficient programmer would probably write:
>
> string PublishedProductsRepo :: CreateStatement() const
> {
> return
> "SELECT DISTINCT "
> "* "
> "FROM "
> "map";
> }


And the next level of proficiency avoids this AntiPattern:

http://c2.com/cgi/wiki?PerniciousIngrownSql

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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: A Weird Appearance for a Weird Site richard HTML 0 01-21-2011 07:10 AM
Re: A Weird Appearance for a Weird Site dorayme HTML 1 01-21-2011 06:51 AM
Re: A Weird Appearance for a Weird Site richard HTML 0 01-21-2011 06:46 AM
what value does lack of return or empty "return;" return Greenhorn C Programming 15 03-06-2005 08:19 PM
getting return value from function without return statement. Seong-Kook Shin C Programming 1 06-18-2004 08:19 AM



Advertisments