uninitialized bool

[rswanster]

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

 

[mlimber]

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

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

 

[John Harrison]

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?

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

 

[Mike Wahler]

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

The output could have been that, any other values,
or nothing at all. The program could do *anything*,
because its behavior is undefined.

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

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

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

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

 

[sjbrown8]

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

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]

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

 

[Greg]

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

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 unpredictability 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]

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.

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.

 

[Alf P. Steinbach]

* Greg:

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.

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.

 

[Greg]

* Greg:

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.

§4.1/1 applies to uninitialized objects. §8.5.9 applies to local
variables declared without an initializer. Such variables are
initialized with an "indeterminate" 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 "indeterminate" 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]

* Greg:

pes.

=A74.1/1 applies to uninitialized objects.
Right.


=A78.5.9 applies to local variables declared without an initializer.
Right.


Such variables are initialized with an "indeterminate" initial value.

Granted in the case of a bool, indeterminate may be neither true or false.
Right.


But for other
integral types, an uninitialized value is always a defined value -

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

and accessing it will not result in undefined behavior.

Wrong, see §4.1/1.

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 "indeterminate" value.
Right.


Surely, if 4.1/1 applied to local
variables without intializers, this resulut of executing this statement
would have to be undefined behavior.
Right.


But it is not.

Wrong, see §4.1/1.

The behavior is
merely indeterminate until the value of x is known.

Wrong, see §4.1/1.


Cheers,

- Alf

 

[mlimber]

[converted top-posting to more readable form]

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

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

 

[sat]

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)