another copy constructor question

[ciccio]

Hi,

I was wondering why in the following piece of code, the function test1
calls a copy constructor at return and why test2 does not. Is the usage
of multiple return statements in one function not really a good
programming style?

Thanks for the help

#include <iostream>

class foo {
public:
foo() { };
foo(const foo &c) { std::cout << "copu" << std::endl; }
};

foo test1() {
if (true) {
foo c;
return c;
}
return foo();
}

foo test2() {
foo c;
if (true) {
}
return c;
}

int main(void) {
std::cout << "test 1" << std::endl;
test1();
std::cout << "test 2" << std::endl;
test2();
return 0;
}

[Victor Bazarov]

ciccio wrote:

I was wondering why in the following piece of code, the function test1
calls a copy constructor at return and why test2 does not. Is the usage
of multiple return statements in one function not really a good
programming style?

Thanks for the help

#include <iostream>

class foo {
public:
foo() { };
foo(const foo &c) { std::cout << "copu" << std::endl; }
};

foo test1() {
if (true) {
foo c;
return c;
}
return foo();
}

foo test2() {
foo c;
if (true) {
}
return c;
}

int main(void) {
std::cout << "test 1" << std::endl;
test1();
std::cout << "test 2" << std::endl;
test2();
return 0;
}

I believe in this case it comes down to the compiler's ability to
optimise the copying away. In one case it can, in the other it cannot,
and that's about it. As to the style of multiple return points, it's up
to the user. Too many moons ago I was taught structured programming,
and a single return point was important. Nowadays if you program using
the RAII paradigm, multiple returns are perfectly OK, AFAICT.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[ademirzanetti]

On Jun 3, 1:06 pm, Victor Bazarov <v.Abaza...@com Acast.netwrote:

ciccio wrote:

I was wondering why in the following piece of code, the function test1
calls a copy constructor at return and why test2 does not. Is the usage
of multiple return statements in one function not really a good
programming style?

Thanks for the help

#include <iostream>

class foo {
public:
foo() { };
foo(const foo &c) { std::cout << "copu" << std::endl; }
};

foo test1() {
if (true) {
foo c;
return c;
}
return foo();
}

foo test2() {
foo c;
if (true) {
}
return c;
}

int main(void) {
std::cout << "test 1" << std::endl;
test1();
std::cout << "test 2" << std::endl;
test2();
return 0;
}

I believe in this case it comes down to the compiler's ability to
optimise the copying away. In one case it can, in the other it cannot,
and that's about it. As to the style of multiple return points, it's up
to the user. Too many moons ago I was taught structured programming,
and a single return point was important. Nowadays if you program using
the RAII paradigm, multiple returns are perfectly OK, AFAICT.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Take a look on the link below where Sutter explain it

http://www.gotw.ca/gotw/002.htm

Note that the question is not regarding performance, it is just about
why in one case the constructor is called and in another it is not.

AZanetti

[Victor Bazarov]

ademirzanetti wrote:

On Jun 3, 1:06 pm, Victor Bazarov <v.Abaza...@com Acast.netwrote:

>ciccio wrote:

>>I was wondering why in the following piece of code, the function test1
calls a copy constructor at return and why test2 does not. Is the usage
of multiple return statements in one function not really a good
programming style?
Thanks for the help
#include <iostream>
class foo {
public:
foo() { };
foo(const foo &c) { std::cout << "copu" << std::endl; }
};
foo test1() {
if (true) {
foo c;
return c;
}
return foo();
}
foo test2() {
foo c;
if (true) {
}
return c;
}
int main(void) {
std::cout << "test 1" << std::endl;
test1();
std::cout << "test 2" << std::endl;
test2();
return 0;
}

I believe in this case it comes down to the compiler's ability to
optimise the copying away. In one case it can, in the other it cannot,
and that's about it. As to the style of multiple return points, it's up
to the user. Too many moons ago I was taught structured programming,
and a single return point was important. Nowadays if you program using
the RAII paradigm, multiple returns are perfectly OK, AFAICT.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Take a look on the link below where Sutter explain it

http://www.gotw.ca/gotw/002.htm

Note that the question is not regarding performance, it is just about
why in one case the constructor is called and in another it is not.

AZanetti

Not sure what your point was or whether you replied to me or to the OP.
Perhaps you could explain what parts of Sutter's GotW #2 apply here and
how. Much appreciated.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Jun 3, 6:06 pm, Victor Bazarov <v.Abaza...@com Acast.netwrote:

ciccio wrote:

I was wondering why in the following piece of code, the
function test1 calls a copy constructor at return and why
test2 does not. Is the usage of multiple return statements
in one function not really a good programming style?

Thanks for the help

#include <iostream>

class foo {
public:
foo() { };
foo(const foo &c) { std::cout << "copu" << std::endl; }
};

foo test1() {
if (true) {
foo c;
return c;
}
return foo();
}

foo test2() {
foo c;
if (true) {
}
return c;
}

int main(void) {
std::cout << "test 1" << std::endl;
test1();
std::cout << "test 2" << std::endl;
test2();
return 0;
}

I believe in this case it comes down to the compiler's ability
to optimise the copying away. In one case it can, in the
other it cannot, and that's about it.

In the end, yes. Probably, the compiler sees that there are
branches which don't return c, and so does not apply NVRO,
although it conceivably could, because in every case c is
constructed, it is the return value.

As to the style of multiple return points, it's up to the
user. Too many moons ago I was taught structured programming,
and a single return point was important. Nowadays if you
program using the RAII paradigm, multiple returns are
perfectly OK, AFAICT.

If you don't care about readable or correct code.

In practice, functions should be small enough that the impact on
readability or correction are minor; there are certainly larger
issues. And there are also special cases where it is
acceptable, or maybe even preferred (a function which consists
of a single switch, with a return in each case). But as a
general rule, its better to avoid.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Frank Birbacher]

Hi!

James Kanze schrieb:

In practice, functions should be small enough that the impact on
readability or correction are minor; there are certainly larger
issues. And there are also special cases where it is
acceptable, or maybe even preferred (a function which consists
of a single switch, with a return in each case). But as a
general rule, its better to avoid.

Reminds me of the ugly:

int foo(int param)
{
int result;
if(bar(param))
{
result = 10;
}
else
{
result = -5;
}
return result;
}

there is mode code necessary to handle the SESE (single entry, single
exit) than there is for actual behaviour. I can't stand it. It's not
readable in my opinion.

Frank

[Jerry Coffin]

In article <6a************ *@mid.dfncis.de >, bl************@ gmx.net
says...

[ ... ]

int foo(int param)
{
int result;
if(bar(param))
{
result = 10;
}
else
{
result = -5;
}
return result;
}

there is mode code necessary to handle the SESE (single entry, single
exit) than there is for actual behaviour. I can't stand it. It's not
readable in my opinion.

This can be made SESE with no flow-control at all:

int foo(int param) {
int rets[-5, 10];

return rets[(bool)bar(param )];
}

No code for anything but the values and the behavior.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <Zc************ *************** ***@posted.comn et>,
al***@start.no says...

* Jerry Coffin:

[ ... ]

int foo(int param) {
int rets[-5, 10];

return rets[(bool)bar(param )];
}

Uhm, I think you must have been coding in some other language recently... ;-)

Nope -- my fondness for such things isn't recent at all. To a large
extent it goes back to my days writing Fortran. Its (nearly) complete
lack of control structures made such code seem quite reasonable.

Anyways, as implicit in my article else-thread, I'd simply use a conditional
expression rather than a look-up.

That's certainly an option, of course. I'll openly admit I'm fond of the
table driven version, quite possibly to an inordinate degree.

That is, if I chose to make this a function at all.

Well yes, there is that. As it stands right now, it looks like a pretty
worthless function, but it was clearly written more to make a point than
with any real purpose in mind. The problem is that in many cases, by the
time you make it useful, the point he was trying to make is like to
disappear.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jun 5, 12:42 am, Frank Birbacher <bloodymir.c... @gmx.netwrote:

James Kanze schrieb:

In practice, functions should be small enough that the impact on
readability or correction are minor; there are certainly larger
issues. And there are also special cases where it is
acceptable, or maybe even preferred (a function which consists
of a single switch, with a return in each case). But as a
general rule, its better to avoid.

Reminds me of the ugly:

int foo(int param)
{
int result;
if(bar(param))
{
result = 10;
}
else
{
result = -5;
}
return result;
}

In that case, the obvious way to write the function is:

int
foo( int param )
{
return bar( param ) ? 10 : -5 ;
}

Anything else is obfuscation.

If the branches become more complex, however, then using the
result variable certainly improves readability.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 5, 2:13 am, Jerry Coffin <jcof...@taeus. comwrote:

In article <6aok2tF38n2s.. [e-mail] >, bloodymir.c...@ gmx.net
says...

[ ... ]

int foo(int param)
{
int result;
if(bar(param))
{
result = 10;
}
else
{
result = -5;
}
return result;
}

there is mode code necessary to handle the SESE (single entry, single
exit) than there is for actual behaviour. I can't stand it. It's not
readable in my opinion.

This can be made SESE with no flow-control at all:

int foo(int param) {
int rets[-5, 10];

I presume that here you meant:

static int const rets[] = { -5, 10 } ;

return rets[(bool)bar(param )];
}

No code for anything but the values and the behavior.

I don't know. I often use something similar instead of a
switch. But somehow the idea of indexing with "bool" doesn't
appeal to me---you're really counting on something that is only
present for hister^H^Horica l reasons: the fact that conversion
of bool to int is guaranteed to return 0 and 1. (*IF* for some
reason I needed to index with a bool, I'd probably write it out
in full: "theBool ? 1 : 0". Conceptually, a bool is NOT an
integral value, regardless of what the language standard says.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]