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

#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;
}

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

On Jun 3, 1:06 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> 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
>
> > #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

ademirzanetti wrote:
> On Jun 3, 1:06 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> 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
>>> #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

On Jun 3, 6:06 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> 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

> > #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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

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

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

Not that I don't agree with your implied conclusion, that fanatical adherence to
SESE is ungood (epecially in C++), but your example doesn't hold water: for this
example, SESE produces the least code, namely 1 line function body, whereas SEME
produces at least 2 lines and depending on formatting in general twice that.

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

So if this is an example of anything related to SESE/SEME, it must be that
fanatical adherence to SEME can produce ungood code.

In general, fanatical adherence to just about anything is ungood. :-)


Cheers, & hth.,

- Alf

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

In article <6aok2tF38n2siU1@mid.dfncis.de>, bloodymir.crap@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 <6aok2tF38n2siU1@mid.dfncis.de>, bloodymir.crap@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)];
> }

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

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

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


Cheers,

- Alf


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

In article <ZcGdnc4DkfHurtrVnZ2dnUVZ_hKdnZ2d@posted.comnet> ,
alfps@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.

* Jerry Coffin:
> In article <ZcGdnc4DkfHurtrVnZ2dnUVZ_hKdnZ2d@posted.comnet> ,
> alfps@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.

Well, I must admit that rather than being fond of error messages, I tend to be
annoyed by them. ;-)


Cheers,

- Alf

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

On Jun 5, 12:42 am, Frank Birbacher <bloodymir.c...@gmx.net> wrote:
> 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jun 5, 2:13 am, Jerry Coffin <jcof...@taeus.com> wrote:
> In article <6aok2tF38n2s...@mid.dfncis.de>, 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^Horical 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Hi!

Alf P. Steinbach schrieb:
> Not that I don't agree with your implied conclusion, that fanatical
> adherence to SESE is ungood (epecially in C++), but your example doesn't
> hold water: for this example, SESE produces the least code, namely 1
> line function body, whereas SEME produces at least 2 lines and depending
> on formatting in general twice that.
>
> int foo( int param )
> {
> return (bar( param )? 10 : -5);
> }

Yes, you are right. I figured I'm actually mixing two things here: SESE
and some programming style. But both to serve the same purpose, that is
"easier" debugging.

I was handed in some code like I posted. I replied the code could be
much easier, e.g. like "return bar(param) ? 10 : -5;". It would be much
shorter, clearer and easier to read. But the author told me about his
former experiences and coding standards he had to use. They would
require explicit curly braces on extra lines and SESE to make debugging
easier because you could actually step through the lines to see which
branch is taken and you could place a single break point at "return" to
see what the "result" was. He was so into it I couldn't even convince
him to replace
if(...)
{
result = true;
}
else
{
result = false;
}

by
result = ...;

and of course not by
return ...;

Personally I couldn't giveup concise code in general to out a bad
debugger.

Frank

In article <630db2ce-1aee-4a55-a9cb-
44053d48682c@a1g2000hsb.googlegroups.com>, james.kanze@gmail.com says...

[ ... ]

> > 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)];
> > }

Yes, now that you mention it, that does look closer to something a
compiler might accept, doesn't it?

> > 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^Horical 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.)

I dunno -- I don't really see a problem with it. I think before I
explicitly converted the bool to an integer, I'd create a tiny (mostly
NOP) class that acted a bit like an array, but took a bool as a
subscript.

--
Later,
Jerry.

The universe is a figment of its own imagination.

In article <naKdnZWStOjRyNrVnZ2dnUVZ_s7inZ2d@posted.comnet> ,
alfps@start.no says...

[ ... ]

> Well, I must admit that rather than being fond of error messages, I tend to be
> annoyed by them. ;-)

Obviously, when I'm tired I can miss even the _extremely_ obvious...

--
Later,
Jerry.

The universe is a figment of its own imagination.