Definition of logical true in C++?

[Lars Uffmann]

If I define a function, that shall return -1 in case of error, and a
positive value otherwise:

int foo (int param) {
if (outOfRange (param))
return -1;

return (param != 0);
}

can I rely on this code always working, or is it possible that the
return statement produces a -1 also, on a specific compiler / OS?
Is this defined somewhere? And if so, where in the standard?

Best Regards,

Lars

[Sebastian Redl]

Lars Uffmann wrote:

can I rely on this code always working, or is it possible that the
return statement produces a -1 also, on a specific compiler / OS?
Is this defined somewhere? And if so, where in the standard?

As defined by 4.5/4, boolean true is promoted to 1, boolean false to 0.
--
Sebastian Redl

[Lars Uffmann]

Sebastian Redl wrote:

As defined by 4.5/4, boolean true is promoted to 1, boolean false to 0.

Thanks, that's all I needed to know - though I just noticed that there's
no easily found online version of the C++ standards - are you able to
point me to one?

Best Regards,

Lars

[Ian Collins]

Lars Uffmann wrote:

Sebastian Redl wrote:

>As defined by 4.5/4, boolean true is promoted to 1, boolean false to 0.

Thanks, that's all I needed to know - though I just noticed that there's
no easily found online version of the C++ standards - are you able to
point me to one?

http://webstore.ansi.org/RecordDetai...IEC+14882-2003

--
Ian Collins.

[=?iso-8859-1?q?Tom=E1s_=D3_h=C9ilidhe?=]

Lars Uffmann:

Argl... That license agreement says "single computer only"... I guess
I'll go for a printed book version :) Amazon, here I come...

I agree with Alf; I had a hard-copy of the Standard one time, it was a
mammoth of a thing and I could find no use for it. I threw it in the thrash
eventually.

You can always just type "14882:2003" into Google and hit "I'm Feeling
Lucky", brings you to exactly what you're looking for.

--
Tomás Ó hÉilidhe

[Gerhard Fiedler]

On 2008-01-21 05:06:41, Lars Uffmann wrote:

If I define a function, that shall return -1 in case of error, and a
positive value otherwise:

int foo (int param) {
if (outOfRange (param))
return -1;

return (param != 0);
}

Just some food for thought... while this may "work", it may not always work
as intended :)

Looks to me as if this is a candidate for either an enum return value or an
exception thrown.

Gerhard

[Juha Nieminen]

Sebastian Redl wrote:

However, the drafts of the standard are freely available

If I'm not completely mistaken, someone has even made man pages from
the C++ standard draft. Any idea where those could be available?

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-01-21 13:13, Gerhard Fiedler wrote:

On 2008-01-21 05:06:41, Lars Uffmann wrote:

>If I define a function, that shall return -1 in case of error, and a
positive value otherwise:

int foo (int param) {
if (outOfRange (param))
return -1;

return (param != 0);
}

Just some food for thought... while this may "work", it may not always work
as intended :)

Looks to me as if this is a candidate for either an enum return value or an
exception thrown.

Or at the very least using code that clearly states the intent:

int foo(int param) {
if (outOfRange(param))
return -1;
else if (param != 0)
return 1;
}

--
Erik Wikström

[Juha Nieminen]

Erik Wikström wrote:

int foo(int param) {
if (outOfRange(param))
return -1;
else if (param != 0)
return 1;
}

Not all paths return a value.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-01-21 23:06, Juha Nieminen wrote:

Erik Wikström wrote:

>int foo(int param) {
if (outOfRange(param))
return -1;
else if (param != 0)
return 1;
}

Not all paths return a value.

Ooops. Forgot

else
return 0;

--
Erik Wikström

[Lars Uffmann]

Erik Wikström wrote:

Or at the very least using code that clearly states the intent:

int foo(int param) {
if (outOfRange(param))
return -1;
else if (param != 0)
return 1;
}

Yes, I could do that - I was hoping to save some computing time on
avoiding the extra if-clause for param != 0 - just return the output of
that. And as Sebastian pointed out, in the standard, boolean true is
promoted to 1 - so I'm safe ;)

Best Regards,

Lars

[Bart van Ingen Schenau]

On 23 jan, 14:34, Lars Uffmann <[e-mail]:

>
Point taken, but I'd like to know the compiler behaviour on this for
sure before I use the more self-explaining code :) Otherwise I'll just
add the appropriate comments to the code. After all, I'm not writing a
book, but trying to program fast applications ;) Self-explaining code
yes, but only as long as it doesn't affect speed in a bad way.

And the best way to adversely affect the speed of your application is
to try to outsmart your compiler. :-)
Optimisers get better all the time, and they work by looking at
patterns within the (generated) code. The first patterns that get
added to an optimiser are those for idiomatic code, because those
should occur very frequently and thus can have a big impact on
optimisation.
Writing non-idiomatic code may result in missed opportunities because
the optimiser does not recognise it.

>
Best Regards,

Lars

Bart v Ingen Schenau