uninitialized bool

Discussion in 'C++' started by rswanster@gmail.com, Sep 29, 2005.

  1. Guest

    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
     
    , Sep 29, 2005
    #1
    1. Advertising

  2. mlimber Guest

    wrote:
    > 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
     
    mlimber, Sep 29, 2005
    #2
    1. Advertising

  3. wrote:
    > 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
     
    John Harrison, Sep 29, 2005
    #3
  4. Mike Wahler Guest

    <> wrote in message
    news:...
    > 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
     
    Mike Wahler, Sep 29, 2005
    #4
  5. Wojtek Guest

    Uzytkownik <> napisal w wiadomosci
    news:...
    > 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
     
    Wojtek, Sep 29, 2005
    #5
  6. Guest

    Wojtek wrote:
    > Uzytkownik <> napisal w wiadomosci
    > news:...
    >
    >>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
    >
    >

    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
     
    , Sep 30, 2005
    #6
  7. sat Guest

    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" <> wrote in message news:dhhmmd$rf8$...
    >
    > Uzytkownik <> napisal w wiadomosci
    > news:...
    >> 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
    >
    >
     
    sat, Sep 30, 2005
    #7
  8. Greg Guest

    John Harrison wrote:
    > wrote:
    > > 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


    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
     
    Greg, Sep 30, 2005
    #8
  9. Pete Becker Guest

    Greg wrote:
    >
    > 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.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Sep 30, 2005
    #9
  10. * 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.

    --
    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?
     
    Alf P. Steinbach, Sep 30, 2005
    #10
  11. Greg Guest

    Alf P. Steinbach wrote:
    > * 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.


    §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
     
    Greg, Sep 30, 2005
    #11
  12. * Greg:
    >
    > Alf P. Steinbach wrote:
    > > * 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 Behav=

    > ior,
    > > per =A74.1/1. However, there is a footnote somewhere discussing in parti=

    > cular
    > > 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 cl=

    > ear.
    > >
    > > In particular, you get both formal and in-practice UB for non-integral ty=

    > 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

    --
    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?
     
    Alf P. Steinbach, Sep 30, 2005
    #12
  13. mlimber Guest

    [converted top-posting to more readable form]

    sat wrote:
    > "Wojtek" wrote:
    > > 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.

    >
    > 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
     
    mlimber, Sep 30, 2005
    #13
  14. sat Guest

    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)




    <> wrote in message news:dhi36t$5u8$...
    > Wojtek wrote:
    >> Uzytkownik <> napisal w wiadomosci
    >> news:...
    >>
    >>>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
    >>
    >>

    > 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, Oct 6, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Weng Tianxiang
    Replies:
    2
    Views:
    470
    Weng Tianxiang
    Jun 21, 2005
  2. Ignacio Machin

    Re: Convert DataRow content to bool

    Ignacio Machin, Jul 7, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    374
    Ignacio Machin
    Jul 7, 2003
  3. Eliyahu Goldin

    Re: Convert DataRow content to bool

    Eliyahu Goldin, Jul 7, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    358
    Eliyahu Goldin
    Jul 7, 2003
  4. Georg Mayer
    Replies:
    1
    Views:
    335
    cosine... zero
    Jun 23, 2004
  5. Patrick Olurotimi Ige

    Cannot implicitly convert type 'object' to 'bool' Error

    Patrick Olurotimi Ige, Jan 25, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    12,214
    Patrick Olurotimi Ige
    Jan 25, 2005
Loading...

Share This Page