uninitialized bool

[rswanster@gmail.com]

When I compile and run the following:

#include <iostream>

int main() {
bool f;
std::cout << f << std::endl;
f = not(f);
std::cout << f << std::endl;
}

I get as output:
8
9

Is this according to spec? Am I required to initialize booleans?

Robert

[John Harrison]

Re: uninitialized bool

rswanster@gmail .com wrote:[color=blue]
> When I compile and run the following:
>
> #include <iostream>
>
> int main() {
> bool f;
> std::cout << f << std::endl;
> f = not(f);
> std::cout << f << std::endl;
> }
>
> I get as output:
> 8
> 9
>
> Is this according to spec?[/color]

Yes, this program has undefined behaviour.

Am I required to initialize booleans?

If you want to avoid something like the above then yes you must
initialize the boolean. Using a uninitialised variable is undefined
behaviour.

john

[mlimber]

Re: uninitialized bool


rswans...@gmail .com wrote:[color=blue]
> When I compile and run the following:
>
> #include <iostream>
>
> int main() {
> bool f;
> std::cout << f << std::endl;
> f = not(f);
> std::cout << f << std::endl;
> }
>
> I get as output:
> 8
> 9
>
> Is this according to spec? Am I required to initialize booleans?
>
> Robert[/color]

Yes. Intrinsic types don't invoke default constructors. You could do
this:

bool f = bool();

But it's better to specify what the default value is.

Cheers! --M

[Mike Wahler]

Re: uninitialized bool


<rswanster@gmai l.com> wrote in message
news:1128024440 .722659.8880@z1 4g2000cwz.googl egroups.com...[color=blue]
> When I compile and run the following:
>
> #include <iostream>
>
> int main() {
> bool f;
> std::cout << f << std::endl;
> f = not(f);
> std::cout << f << std::endl;
> }
>
> I get as output:
> 8
> 9[/color]

The output could have been that, any other values,
or nothing at all. The program could do *anything*,
because its behavior is undefined.
[color=blue]
>
> Is this according to spec? Am I required to initialize booleans?[/color]

*Any* object of *any* type must have been initialized or
assigned a valid value before its value can be evaluated,
otherwise the behavior is undefined. With standard library
types, initialization happens automatically via a default
constructor. So with a statement such as

std::string s;

it might look as though 's' is not being initialized, but it is
(in this case to an empty string).

Except for types with default constructors (and objects with
static storage duration), you should *always* provide an
initial value when you define them.

-Mike

[Wojtek]

Re: uninitialized bool


Uzytkownik <rswanster@gmai l.com> napisal w wiadomosci
news:1128024440 .722659.8880@z1 4g2000cwz.googl egroups.com...[color=blue]
> When I compile and run the following:
>
> #include <iostream>
>
> int main() {
> bool f;
> std::cout << f << std::endl;
> f = not(f);
> std::cout << f << std::endl;
> }
>
> I get as output:
> 8
> 9
>
> Is this according to spec? Am I required to initialize booleans?
>
> Robert
>[/color]

Yes, You have to initialize booleans if You want to avoid this undefined
bahaviour, but in global range You don't have to do it.

Wojtas

[sat]

Re: uninitialized bool

Wojtek is rite..
to add, you dont need to initialize the bool, even if it is defined as
static.

In general, all intrinsic data types are set to 0 when defined under global
scope or when defined static..


Sat

"Wojtek" <wsheepw@vp.p l> wrote in message news:dhhmmd$rf8 $1@news.onet.pl ...[color=blue]
>
> Uzytkownik <rswanster@gmai l.com> napisal w wiadomosci
> news:1128024440 .722659.8880@z1 4g2000cwz.googl egroups.com...[color=green]
>> When I compile and run the following:
>>
>> #include <iostream>
>>
>> int main() {
>> bool f;
>> std::cout << f << std::endl;
>> f = not(f);
>> std::cout << f << std::endl;
>> }
>>
>> I get as output:
>> 8
>> 9
>>
>> Is this according to spec? Am I required to initialize booleans?
>>
>> Robert
>>[/color]
>
> Yes, You have to initialize booleans if You want to avoid this undefined
> bahaviour, but in global range You don't have to do it.
>
> Wojtas
>
>[/color]

[Greg]

Re: uninitialized bool

John Harrison wrote:[color=blue]
> rswanster@gmail .com wrote:[color=green]
> > When I compile and run the following:
> >
> > #include <iostream>
> >
> > int main() {
> > bool f;
> > std::cout << f << std::endl;
> > f = not(f);
> > std::cout << f << std::endl;
> > }
> >
> > I get as output:
> > 8
> > 9
> >
> > Is this according to spec?[/color]
>
> Yes, this program has undefined behaviour.
>
> Am I required to initialize booleans?
>
> If you want to avoid something like the above then yes you must
> initialize the boolean. Using a uninitialised variable is undefined
> behaviour.
>
> john[/color]

Actually, the value of an uninitialized local variable is merely
indeterminate - meaning that the program's behavior is defined, but
varies depending on whatever the uninitialized value turns out to be.

But once that value is known, the program behaves no differently than
it would have had it explicitly initialized the variable with that
value to begin with. In other words, the program above is just as well
defined as an identical version that had initialized f to 7.

Being uninitialized, the variable's value could turn out to be any
value. This unpredictabilit y is rarely useful or intended, which is why
it is a good idea to initialize local variables. Nevertheless, using an
uninitialized variable does not by itself entail undefined behavior.

Greg

[Pete Becker]

Re: uninitialized bool

Greg wrote:[color=blue]
>
> But once that value is known, the program behaves no differently than
> it would have had it explicitly initialized the variable with that
> value to begin with. In other words, the program above is just as well
> defined as an identical version that had initialized f to 7.
>[/color]

You can't initialize a bool to 7. You can initialize it with the value
7, but that value will be converted to true, and the resulting code will
not act at all like the original code.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Alf P. Steinbach]

Re: uninitialized bool

* Greg:[color=blue]
>
> Actually, the value of an uninitialized local variable is merely
> indeterminate - meaning that the program's behavior is defined, but
> varies depending on whatever the uninitialized value turns out to be.[/color]

Nope.

In practice that is the case for built-in integral types, but formally it's
not so. Use of the value of an uninitialized variable is Undefined Behavior,
per §4.1/1. However, there is a footnote somewhere discussing in particular
the use of a 'bool' uninitialized variable, mentioning that it can behave as
if it's neither 'true' nor 'false' -- so the standard isn't entirely clear.

In particular, you get both formal and in-practice UB for non-integral types.

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

[Greg]

Re: uninitialized bool


Alf P. Steinbach wrote:[color=blue]
> * Greg:[color=green]
> >
> > Actually, the value of an uninitialized local variable is merely
> > indeterminate - meaning that the program's behavior is defined, but
> > varies depending on whatever the uninitialized value turns out to be.[/color]
>
> Nope.
>
> In practice that is the case for built-in integral types, but formally it's
> not so. Use of the value of an uninitialized variable is Undefined Behavior,
> per §4.1/1. However, there is a footnote somewhere discussing in particular
> the use of a 'bool' uninitialized variable, mentioning that it can behaveas
> if it's neither 'true' nor 'false' -- so the standard isn't entirely clear.
>
> In particular, you get both formal and in-practice UB for non-integral types.[/color]

§4.1/1 applies to uninitialized objects. §8.5.9 applies to local
variables declared without an initializer. Such variables are
initialized with an "indetermin ate" initial value. Granted in the case
of a bool, indeterminate may be neither true or false. But for other
integral types, an uninitialized value is always a defined value - and
accessing it will not result in undefined behavior. The Standard has an
example that makes this point clear [3.3.1]:

int x = x;

The Standard notes that in the above statement x is initialized with
its own "indetermin ate" value. Surely, if 4.1/1 applied to local
variables without intializers, this resulut of executing this statement
would have to be undefined behavior. But it is not. The behavior is
merely indeterminate until the value of x is known.

Greg

[Alf P. Steinbach]

Re: uninitialized bool

* Greg:[color=blue]
>
> Alf P. Steinbach wrote:[color=green]
> > * Greg:[color=darkred]
> > >
> > > Actually, the value of an uninitialized local variable is merely
> > > indeterminate - meaning that the program's behavior is defined, but
> > > varies depending on whatever the uninitialized value turns out to be.[/color]
> >
> > Nope.
> >
> > In practice that is the case for built-in integral types, but formally it=[/color]
> 's[color=green]
> > not so. Use of the value of an uninitialized variable is Undefined Behav=[/color]
> ior,[color=green]
> > per =A74.1/1. However, there is a footnote somewhere discussing in parti=[/color]
> cular[color=green]
> > the use of a 'bool' uninitialized variable, mentioning that it can behave=[/color]
> as[color=green]
> > if it's neither 'true' nor 'false' -- so the standard isn't entirely cl=[/color]
> ear.[color=green]
> >
> > In particular, you get both formal and in-practice UB for non-integral ty=[/color]
> pes.
>
> =A74.1/1 applies to uninitialized objects.[/color]

Right.

[color=blue]
> =A78.5.9 applies to local variables declared without an initializer.[/color]

Right.

[color=blue]
> Such variables are initialized with an "indetermin ate" initial value.[/color]

[color=blue]
> Granted in the case of a bool, indeterminate may be neither true or false.[/color]

Right.

[color=blue]
> But for other
> integral types, an uninitialized value is always a defined value -[/color]

In pratice yes, formally no. Even the in-practice has been disputed.
However, such arguments rely on archaic and/or wholly hypothetical computers
with padding bits -- and we don't want to open that can of worms here... ;-)

[color=blue]
> and accessing it will not result in undefined behavior.[/color]

Wrong, see §4.1/1.

[color=blue]
> The Standard has an
> example that makes this point clear [3.3.1]:
>
> int x =3D x;
>
> The Standard notes that in the above statement x is initialized with
> its own "indetermin ate" value.[/color]

Right.

[color=blue]
> Surely, if 4.1/1 applied to local
> variables without intializers, this resulut of executing this statement
> would have to be undefined behavior.[/color]

Right.

[color=blue]
> But it is not.[/color]

Wrong, see §4.1/1.

[color=blue]
> The behavior is
> merely indeterminate until the value of x is known.[/color]

Wrong, see §4.1/1.


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?

[mlimber]

Re: uninitialized bool

[converted top-posting to more readable form]

sat wrote:[color=blue]
> "Wojtek" wrote:[color=green]
> > Yes, You have to initialize booleans if You want to avoid this undefined
> > bahaviour, but in global range You don't have to do it.[/color]
>
> Wojtek is rite..
> to add, you dont need to initialize the bool, even if it is defined as
> static.
>
> In general, all intrinsic data types are set to 0 when defined under global
> scope or when defined static..[/color]

To be more precise, any intrinsic object that is static -- i.e.,
declared static (whether local or at file scope) or is declared in a
namespace (whether global, unnamed, or named) -- is automatically
initialized to 0, converted to the appropriate type. For user-defined
types, the default constructor will be called if it exists, and an
error will result if one does not exist but other constructors do. If
the default constructor was implicitly generated (i.e. no constructors
were defined), data members are default initialized if the object is
static. Consider:

#include <iostream>
using namespace std;

// Note: no default constructor
struct A { int i_; };

// Namespace-scoped object is default initialized
namespace { A a; }

int main()
{
// Local object is not default initialized
A b;
cout << a.i_ << ' ' << b.i_ << endl;
return 0;
}

The result of the cout demonstrates that a.i_ is initialized to 0, but
b.i_ is not (though it may happen to be 0, of course).

IME, however, it is best to make initialization explicit even in the
case of static objects since this is a rather obscure rule and
explicitness here is far from burdensome and makes the intent of the
programmer clear. Also note that the use of static to indicate "local
to this translation unit" is deprecated in C++ in favor of unnamed
namespaces.

Cheers! --M

[sjbrown8@eng.usf.edu]

Re: uninitialized bool

Wojtek wrote:[color=blue]
> Uzytkownik <rswanster@gmai l.com> napisal w wiadomosci
> news:1128024440 .722659.8880@z1 4g2000cwz.googl egroups.com...
>[color=green]
>>When I compile and run the following:
>>
>>#include <iostream>
>>
>>int main() {
>> bool f;
>> std::cout << f << std::endl;
>> f = not(f);
>> std::cout << f << std::endl;
>>}
>>
>>I get as output:
>>8
>>9
>>
>>Is this according to spec? Am I required to initialize booleans?
>>
>>Robert
>>[/color]
>
>
> Yes, You have to initialize booleans if You want to avoid this undefined
> bahaviour, but in global range You don't have to do it.
>
> Wojtas
>
>[/color]
But I thought the 0 was false and any non-zero value is true; therefore,
if the uninitialized variable is nonzero and gets complimented, it ends
up zero, and vice versa.

-Steve

[sat]

Re: uninitialized bool

you are right upto the part that, non zero values are considered true and
zero is considered false,
but,

there are two kinds of nots or compliment operations:
1. Boolean not .. using the symbol ! b= !b;
2. Binary not.. or negation using the symbol ~ b=~b;

in the first case, a non zero integer would be made zero, and hence false.
but in the second case, all 1 bits are set to 0 and 0 bits are set to 1 in
the integer, resulting in a binary negation,
so if you are using a non zero integer, almost all the time you would end
up with another non zero integer when the binary not is used. (except when
all the bits in the number are 1s)




<sjbrown8@eng.u sf.edu> wrote in message news:dhi36t$5u8 $1@news1.usf.ed u...[color=blue]
> Wojtek wrote:[color=green]
>> Uzytkownik <rswanster@gmai l.com> napisal w wiadomosci
>> news:1128024440 .722659.8880@z1 4g2000cwz.googl egroups.com...
>>[color=darkred]
>>>When I compile and run the following:
>>>
>>>#include <iostream>
>>>
>>>int main() {
>>> bool f;
>>> std::cout << f << std::endl;
>>> f = not(f);
>>> std::cout << f << std::endl;
>>>}
>>>
>>>I get as output:
>>>8
>>>9
>>>
>>>Is this according to spec? Am I required to initialize booleans?
>>>
>>>Robert
>>>[/color]
>>
>>
>> Yes, You have to initialize booleans if You want to avoid this undefined
>> bahaviour, but in global range You don't have to do it.
>>
>> Wojtas
>>
>>[/color]
> But I thought the 0 was false and any non-zero value is true; therefore,
> if the uninitialized variable is nonzero and gets complimented, it ends up
> zero, and vice versa.
>
> -Steve[/color]