Absense of bool

Discussion in 'C Programming' started by AommiK, Nov 3, 2007.

  1. AommiK

    AommiK Guest

    First of all: I love C and think that it's beautiful. However, there is
    at least one MAJOR flaw: the lack of a boolean type.

    OK. Some of you might refer to C99 and its _Bool (what's up with the
    uppercase 'B' anyway?) and the header you can include (apparently) to
    get a real "bool". This isn't my point, however -- it should have been
    there from the beginning.

    Char is a small int. We all know that. However, "char some_bool = 0;"
    simply feels wrong, and I think that most of you agree. Plus, it's
    still too large.

    "int some_bool = 0;" is what I -- and everyone else, I assume -- use
    for bools. But an int is a very large data type for something that will
    only ever be true or false (1 or 0). This really, really bugs me.

    Why, back when C was designed, didn't they see a reason to build in a
    boolean type into the language? Now it matters less, I guess, but back
    then, there should have been very strong technical reasons. It just
    doesn't make any sense whatsoever to me.

    I have asked many people about this for quite some time, and they are
    all just telling me that I'm silly for bringing it up. Why? It's not
    that I NEED a bool to get anything done -- it's the principle. Saving
    resources and coding a little more prettily is a Good Thing (TM) IMO.

    So... can somebody properly explain this to me once and for all? I'm
    sure there MUST be a logical explanation that nobody seems to really
    understand. The madness must end.

    bool some_bool = 0; /* How great it would be... */
    AommiK, Nov 3, 2007
    #1
    1. Advertising

  2. "AommiK" <> wrote in message
    > Why, back when C was designed, didn't they see a reason to build in a
    > boolean type into the language? Now it matters less, I guess, but back
    > then, there should have been very strong technical reasons. It just
    > doesn't make any sense whatsoever to me.
    >

    C is portable assembly. Generally there is no way of manipulating single
    bits with assembly instructions, though of course you can do so with a
    combination of instructions.
    So bool wasn't included.
    We've moved on a little since, and there is quite a good case for it, since
    it doucments that a variable is flag, and that is frequently what we want.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Nov 3, 2007
    #2
    1. Advertising

  3. AommiK

    santosh Guest

    AommiK wrote:

    > First of all: I love C and think that it's beautiful. However, there
    > is at least one MAJOR flaw: the lack of a boolean type.


    At best this is a minor irritation, not a major flaw IMHO.

    > OK. Some of you might refer to C99 and its _Bool (what's up with the
    > uppercase 'B' anyway?) and the header you can include (apparently) to
    > get a real "bool". This isn't my point, however -- it should have been
    > there from the beginning.


    It was not a badly felt need during much of C's evolution and still is
    not.

    > Char is a small int. We all know that. However, "char some_bool = 0;"
    > simply feels wrong, and I think that most of you agree. Plus, it's
    > still too large.


    Use bitfields.

    > "int some_bool = 0;" is what I -- and everyone else, I assume -- use
    > for bools. But an int is a very large data type for something that
    > will only ever be true or false (1 or 0). This really, really bugs me.
    >
    > Why, back when C was designed, didn't they see a reason to build in a
    > boolean type into the language? Now it matters less, I guess, but back
    > then, there should have been very strong technical reasons. It just
    > doesn't make any sense whatsoever to me.


    Because bool is too often an overrated type. In anycase with most
    machines bool is simulated by either a byte of a packed type.

    If you're bothered about space why not use bitfields?

    > I have asked many people about this for quite some time, and they are
    > all just telling me that I'm silly for bringing it up. Why? It's not
    > that I NEED a bool to get anything done -- it's the principle. Saving
    > resources and coding a little more prettily is a Good Thing (TM) IMO.


    This can be done. It wasn't important enough to be Standardised.

    > bool some_bool = 0; /* How great it would be... */


    You can do this since C99.
    santosh, Nov 4, 2007
    #3
  4. AommiK

    James Kuyper Guest

    AommiK wrote:
    ....
    > OK. Some of you might refer to C99 and its _Bool (what's up with the
    > uppercase 'B' anyway?) and the header you can include (apparently) to


    The committee chose a name that is reserved to the implementation for
    ALL uses, in order to avoid breaking any code that currently defined
    'bool' with a conflicting meaning. They couldn't use _bool, either,
    because that name is reserved only " for use as identifiers with file
    scope in both the ordinary and tag name spaces."
    James Kuyper, Nov 4, 2007
    #4
  5. On Nov 3, 10:56 pm, AommiK <> wrote:
    > First of all: I love C and think that it's beautiful. However, there is
    > at least one MAJOR flaw: the lack of a boolean type.


    Why is that a MAJOR flaw? I have trouble seeing it as even a minor
    flaw.

    > OK. Some of you might refer to C99 and its _Bool (what's up with the
    > uppercase 'B' anyway?) and the header you can include (apparently) to
    > get a real "bool". This isn't my point, however -- it should have been
    > there from the beginning.


    Why?

    > Char is a small int. We all know that. However, "char some_bool = 0;"
    > simply feels wrong,


    Why?

    > and I think that most of you agree.


    I doubt that very much.

    > Plus, it's still too large.


    It's typically the smallest addressable type. If you want smaller
    (with the added overhead of more code to implement it) use a bit
    field.

    > "int some_bool = 0;" is what I -- and everyone else, I assume -- use
    > for bools.


    Why do you assume that?

    > But an int is a very large data type for something that will
    > only ever be true or false (1 or 0). This really, really bugs me.
    >
    > Why, back when C was designed, didn't they see a reason to build in a
    > boolean type into the language?


    That's a very silly question. They didn't see a need for it because
    they didn't see a need for it. You need to explain why you think they
    should have seen a need for it.

    > Now it matters less, I guess, but back
    > then, there should have been very strong technical reasons. It just
    > doesn't make any sense whatsoever to me.


    A value of zero is false, non-zero is true. Why do you need a
    particular type to hold the value?

    > I have asked many people about this for quite some time, and they are
    > all just telling me that I'm silly for bringing it up. Why?


    You're not necessarily silly for bringing it up, but you're doing it
    in a silly way. You need to explain why you think it was needed, and
    why anyone should have seen a need for it. You seem to assume that
    everyone shares your view of C and its history and agrees with you for
    some reason.

    > It's not
    > that I NEED a bool to get anything done -- it's the principle. Saving
    > resources and coding a little more prettily is a Good Thing (TM) IMO.


    How would it save resources? A boolean type smaller than char would
    require more resources to implement and at run time. How would it make
    coding any prettier?

    > So... can somebody properly explain this to me once and for all? I'm
    > sure there MUST be a logical explanation that nobody seems to really
    > understand. The madness must end.


    I've no idea what you're talking about.

    > bool some_bool = 0; /* How great it would be... */


    It's there in C99, pretty pointlessly I think. What is the advantage
    of this type? What does it buy me over char or int?
    J. J. Farrell, Nov 4, 2007
    #5
  6. AommiK <> writes:
    > First of all: I love C and think that it's beautiful. However, there is
    > at least one MAJOR flaw: the lack of a boolean type.
    >
    > OK. Some of you might refer to C99 and its _Bool (what's up with the
    > uppercase 'B' anyway?) and the header you can include (apparently) to
    > get a real "bool". This isn't my point, however -- it should have been
    > there from the beginning.
    >
    > Char is a small int. We all know that. However, "char some_bool = 0;"
    > simply feels wrong, and I think that most of you agree. Plus, it's
    > still too large.
    >
    > "int some_bool = 0;" is what I -- and everyone else, I assume -- use
    > for bools. But an int is a very large data type for something that will
    > only ever be true or false (1 or 0). This really, really bugs me.

    [...]

    On typical systems, allocating 8 or more bits to an object intended
    only to hold the values 0 and actually saves space. Accessing a
    single bit, without disturbing the rest of the byte or word that it's
    a part of, is more expensive than accessing the entire byte or word.
    Most CPUs can't directly address single bits.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 4, 2007
    #6
  7. "J. J. Farrell" <> writes:
    > On Nov 3, 10:56 pm, AommiK <> wrote:

    [...]
    >> bool some_bool = 0; /* How great it would be... */

    >
    > It's there in C99, pretty pointlessly I think. What is the advantage
    > of this type? What does it buy me over char or int?


    Documentation.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 4, 2007
    #7
  8. AommiK

    Eric Sosman Guest

    AommiK wrote:
    > First of all: I love C and think that it's beautiful. However, there is
    > at least one MAJOR flaw: the lack of a boolean type.


    It's probably this "MAJOR" flaw that has kept C on the
    sidelines and prevented it from gaining any noticeable following.

    > OK. Some of you might refer to C99 and its _Bool (what's up with the
    > uppercase 'B' anyway?) and the header you can include (apparently) to
    > get a real "bool". This isn't my point, however -- it should have been
    > there from the beginning.
    >
    > Char is a small int. We all know that. However, "char some_bool = 0;"
    > simply feels wrong, and I think that most of you agree. Plus, it's
    > still too large.
    >
    > "int some_bool = 0;" is what I -- and everyone else, I assume -- use
    > for bools. But an int is a very large data type for something that will
    > only ever be true or false (1 or 0). This really, really bugs me.


    If you'll spend several dozens of hours and many thousands
    of dollars to lie on a couch and chat with a professional about
    your dreams and your early childhood memories, your obsession
    may turn out to be curable.

    > Why, back when C was designed, didn't they see a reason to build in a
    > boolean type into the language? Now it matters less, I guess, but back
    > then, there should have been very strong technical reasons. It just
    > doesn't make any sense whatsoever to me.


    I sympathize. For me, the thing that makes no sense whatsoever
    is quantum entanglement. However, the fact that it makes no sense
    to me doesn't impel me to the belief that QE is a "MAJOR" flaw in
    Nature. You seem to attach more importance to your own befuddlement
    than I do to mine.

    > I have asked many people about this for quite some time, and they are
    > all just telling me that I'm silly for bringing it up. Why? It's not
    > that I NEED a bool to get anything done -- it's the principle. Saving
    > resources and coding a little more prettily is a Good Thing (TM) IMO.


    Kidding aside, there's the crux: You declare that you do not
    need a Boolean type "to get anything done."

    Say your words over again, slowly: You claim you

    DO

    NOT

    NEED

    a Boolean type. Why, then, is C deficient in a "MAJOR" way for
    lacking what you DO. NOT. NEED? C also lacks quaternions, nested
    functions, three-way ifs, and the kitchen sink -- "MAJOR" omissions
    all, I guess you'd say, whether you would use them or not.

    > So... can somebody properly explain this to me once and for all? I'm
    > sure there MUST be a logical explanation that nobody seems to really
    > understand. The madness must end.


    The "madness," if you choose to think of it that way, ended
    eight years ago. Haven't you grown weary of tearing your hair
    and rending your clothing? Aren't the sackcloth and ashes
    getting a little tiresome? Your stamina is admirable, but ...

    > bool some_bool = 0; /* How great it would be... */


    Go ahead. No one is stopping you, except possibly your peers
    in code review who will (1) object to your idiosyncratic way of
    spelling `false' and (2) ask what the purpose of `some_bool' is.
    In my experience, programs in all programming languages use Boolean
    *values* all the time, but the use of Boolean *variables* is far
    rarer.

    --
    Eric Sosman
    lid
    Eric Sosman, Nov 4, 2007
    #8
  9. AommiK wrote:
    > First of all: I love C and think that it's beautiful. However, there is
    > at least one MAJOR flaw: the lack of a boolean type.
    >
    > OK. Some of you might refer to C99 and its _Bool (what's up with the
    > uppercase 'B' anyway?) and the header you can include (apparently) to
    > get a real "bool". This isn't my point, however -- it should have been
    > there from the beginning.
    >
    > Char is a small int. We all know that. However, "char some_bool = 0;"
    > simply feels wrong, and I think that most of you agree. Plus, it's
    > still too large.


    Do you have an example of a language with a boolean type which will
    store the boolean in a location smaller than a byte?

    (C optimizers are allowed to reduce the size used by bool types; but I
    would guess that the performance hit by requiring all those extra
    bit-twiddling operations would generally be considered to much.)

    I agree that it's useful to have a bool type for code readability
    purposes; but you have always been able to typedef one. However I'm just
    not convinced that a bool should be stored by default in a single bit,
    within a byte shared with other bool values.

    --
    Philip Potter pgp <at> doc.ic.ac.uk
    Philip Potter, Nov 4, 2007
    #9
  10. AommiK

    Army1987 Guest

    On Sun, 04 Nov 2007 09:53:31 +0000, Philip Potter wrote:

    > (C optimizers are allowed to reduce the size used by bool types; but I
    > would guess that the performance hit by requiring all those extra
    > bit-twiddling operations would generally be considered to much.)


    They can't. See 6.2.6.1p2.
    Also, I must be allowed to access them as arrays of unsigned char,
    if several _Bool are stored in the same byte
    memset(&bool_var, 0, sizeof bool_var) could affect other ones,
    which 6.2.4p2 forbids. Also, if the bytes of an object are
    themselves objects, if I do *(unsigned char *)&bool_var = '/';
    that byte will stay the same until I access bool_var again (it
    could change even if I just *read* it, because '/' could be a
    trap representation for _Bool causing UB, but if I don't access it
    at all, it can't change).
    As I see it, _Bool is required to have at least seven padding
    bits. (Anyway, I think that if a _Bool is declared as register, or
    if the compiler pretends that it is because its address is never
    taken, it might not actually store them anywhere.)
    --
    Army1987 (Replace "NOSPAM" with "email")
    A hamburger is better than nothing.
    Nothing is better than eternal happiness.
    Therefore, a hamburger is better than eternal happiness.
    Army1987, Nov 4, 2007
    #10
  11. AommiK

    Army1987 Guest

    On Sat, 03 Nov 2007 19:05:56 -0700, J. J. Farrell wrote:

    > It's there in C99, pretty pointlessly I think. What is the advantage
    > of this type? What does it buy me over char or int?

    The fact that the implementation can choose which one it is.
    (So can it with enum { false, true }, but the latter in some
    implementations turns out to be much larger.)
    Also, (char)0.1 and (int)I are zero, whereas (_Bool)0.1 and
    (_Bool)I are one.
    --
    Army1987 (Replace "NOSPAM" with "email")
    A hamburger is better than nothing.
    Nothing is better than eternal happiness.
    Therefore, a hamburger is better than eternal happiness.
    Army1987, Nov 4, 2007
    #11
  12. AommiK

    Army1987 Guest

    On Sat, 03 Nov 2007 19:05:56 -0700, J. J. Farrell wrote:

    > It's there in C99, pretty pointlessly I think. What is the advantage
    > of this type? What does it buy me over char or int?

    The fact that the implementation can choose which one it is.
    (So can it with enum { false, true }, but the latter in some
    implementations turns out to be much larger.)
    Also, (char)0.1 and (int)I are zero, whereas (_Bool)0.1 and
    (_Bool)I are one. (But one could simply write
    char foo = (bar != 0); so that doesn't buy much...)
    --
    Army1987 (Replace "NOSPAM" with "email")
    A hamburger is better than nothing.
    Nothing is better than eternal happiness.
    Therefore, a hamburger is better than eternal happiness.
    Army1987, Nov 4, 2007
    #12
  13. On Sun, 04 Nov 2007 12:09:26 +0100, Army1987 wrote:
    > On Sun, 04 Nov 2007 09:53:31 +0000, Philip Potter wrote:
    >
    >> (C optimizers are allowed to reduce the size used by bool types; but I
    >> would guess that the performance hit by requiring all those extra
    >> bit-twiddling operations would generally be considered to much.)

    >
    > They can't.


    They can for those booleans that never have their address taken.
    =?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F, Nov 4, 2007
    #13
  14. AommiK

    Richard Guest

    "J. J. Farrell" <> writes:

    > On Nov 3, 10:56 pm, AommiK <> wrote:
    >> First of all: I love C and think that it's beautiful. However, there is
    >> at least one MAJOR flaw: the lack of a boolean type.

    >
    > Why is that a MAJOR flaw? I have trouble seeing it as even a minor
    > flaw.


    I see it as a flaw. A minor one. But a flaw nonetheless.

    >
    >> OK. Some of you might refer to C99 and its _Bool (what's up with the
    >> uppercase 'B' anyway?) and the header you can include (apparently) to
    >> get a real "bool". This isn't my point, however -- it should have been
    >> there from the beginning.

    >
    > Why?


    Because C is a programming language that applies all sorts of rules on
    other types and a C program uses boolean decision making every other
    line or so ....

    >
    >> Char is a small int. We all know that. However, "char some_bool = 0;"
    >> simply feels wrong,

    >
    > Why?


    Because it's not a true "boolean". When you see a char its not obvious
    fro the type that it's a binary indicator. Fairly obvious I would have
    thought.


    >
    >> and I think that most of you agree.

    >
    > I doubt that very much.
    >


    Lets turn it around. Why would you think having a real boolean is NOT a
    good idea?
    Richard, Nov 4, 2007
    #14
  15. Harald van Dij殺俎k wrote:
    > On Sun, 04 Nov 2007 12:09:26 +0100, Army1987 wrote:
    >> On Sun, 04 Nov 2007 09:53:31 +0000, Philip Potter wrote:
    >>
    >>> (C optimizers are allowed to reduce the size used by bool types; but I
    >>> would guess that the performance hit by requiring all those extra
    >>> bit-twiddling operations would generally be considered to much.)

    >> They can't.

    >
    > They can for those booleans that never have their address taken.


    Yes, I was relying on this and the as-if rule.

    --
    Philip Potter pgp <at> doc.ic.ac.uk
    Philip Potter, Nov 4, 2007
    #15
  16. On Nov 4, 4:09 pm, Richard <> wrote:
    > "J. J. Farrell" <> writes:
    >
    > > On Nov 3, 10:56 pm, AommiK <> wrote:
    > >> First of all: I love C and think that it's beautiful. However, there is
    > >> at least one MAJOR flaw: the lack of a boolean type.

    >
    > > Why is that a MAJOR flaw? I have trouble seeing it as even a minor
    > > flaw.

    >
    > I see it as a flaw. A minor one. But a flaw nonetheless.
    >
    >
    >
    > >> OK. Some of you might refer to C99 and its _Bool (what's up with the
    > >> uppercase 'B' anyway?) and the header you can include (apparently) to
    > >> get a real "bool". This isn't my point, however -- it should have been
    > >> there from the beginning.

    >
    > > Why?

    >
    > Because C is a programming language that applies all sorts of rules on
    > other types and a C program uses boolean decision making every other
    > line or so ....
    >
    >
    >
    > >> Char is a small int. We all know that. However, "char some_bool = 0;"
    > >> simply feels wrong,

    >
    > > Why?

    >
    > Because it's not a true "boolean". When you see a char its not obvious
    > fro the type that it's a binary indicator. Fairly obvious I would have
    > thought.
    >
    >
    >
    > >> and I think that most of you agree.

    >
    > > I doubt that very much.

    >
    > Lets turn it around. Why would you think having a real boolean is NOT a
    > good idea?
    J. J. Farrell, Nov 4, 2007
    #16
  17. Apologies for the previous unedited reply.

    On Nov 4, 4:09 pm, Richard <> wrote:
    > "J. J. Farrell" <> writes:
    >
    > > On Nov 3, 10:56 pm, AommiK <> wrote:
    > >> First of all: I love C and think that it's beautiful. However, there is
    > >> at least one MAJOR flaw: the lack of a boolean type.

    >
    > > Why is that a MAJOR flaw? I have trouble seeing it as even a minor
    > > flaw.

    >
    > I see it as a flaw. A minor one. But a flaw nonetheless.
    >
    > ...
    >
    > Lets turn it around. Why would you think having a real boolean is NOT a
    > good idea?


    I don't think that, and never suggested that I did. I don't have any
    strong feelings on the subject at all. I'm not sure that I consider
    it's absence a flaw, but if it is it's a very minor one. I wouldn't
    object to its presence; its usefulness might outweigh the complexity
    it would add, but by very little. Overall it doesn't much matter
    either way in my opinion.

    The only real utility I can see in it is self-documentation of code,
    but that's easily achieved by a programmer-defined typedef or even by
    the name of the variable. It doesn't seem to warrant a fundamental
    type.

    I'm just puzzled why someone should see its absence as a MAJOR flaw,
    to the extent that they can't conceive that the need for it didn't
    occur to the inventors of the language. That's why I was asking.
    J. J. Farrell, Nov 4, 2007
    #17
  18. AommiK

    santosh Guest

    Richard wrote:
    > "J. J. Farrell" <> writes:
    >> On Nov 3, 10:56 pm, AommiK <> wrote:


    >>> OK. Some of you might refer to C99 and its _Bool (what's up with the
    >>> uppercase 'B' anyway?) and the header you can include (apparently)
    >>> to get a real "bool". This isn't my point, however -- it should have
    >>> been there from the beginning.

    >>
    >> Why?

    >
    > Because C is a programming language that applies all sorts of rules on
    > other types and a C program uses boolean decision making every other
    > line or so ....


    And in C boolean decision making doesn't require a boolean type.

    >>> Char is a small int. We all know that. However, "char some_bool =
    >>> 0;" simply feels wrong,

    >>
    >> Why?

    >
    > Because it's not a true "boolean".


    C defines zero as boolean false and any other value as boolean true, in
    a boolean context. A specific boolean type isn't necessary except for
    aesthetic purposes.

    > When you see a char its not obvious
    > fro the type that it's a binary indicator.


    That's what typedefs are for. Also the object's name should convey it's
    intended boolean usage.

    > Fairly obvious I would have thought.


    It's also fairly obvious that unlike languages like C#, C doesn't
    require a boolean type; any value is interpreted as true or false
    according to a simple rule.

    Anyway the latest C standard _has_ mandated a boolean type, for whatever
    it's worth.

    However the OP was complaining about the lack of single bit boolean
    types and the supposed wasted storage by using a char or int or
    whatever.

    Now, as far as I can see, there is no readily apparent reason against
    implementing a bit type in C. However the fact that C conveniently
    treats any integer value as either true or false, when in a boolean
    context, combined with the probable loss of execution efficiency in
    manipulating a bit type, meant that a specific boolean bit type was not
    (and is not) felt as very essential to the language.

    > Lets turn it around. Why would you think having a real boolean is NOT
    > a good idea?


    No one said it was not a good idea. Probable reasons were supplied for
    why it was not built into the language from it's beginning. That does
    not imply that boolean types are either good or bad.
    santosh, Nov 4, 2007
    #18
  19. AommiK

    Richard Guest

    "J. J. Farrell" <> writes:

    > Apologies for the previous unedited reply.
    >
    > On Nov 4, 4:09 pm, Richard <> wrote:
    >> "J. J. Farrell" <> writes:
    >>
    >> > On Nov 3, 10:56 pm, AommiK <> wrote:
    >> >> First of all: I love C and think that it's beautiful. However, there is
    >> >> at least one MAJOR flaw: the lack of a boolean type.

    >>
    >> > Why is that a MAJOR flaw? I have trouble seeing it as even a minor
    >> > flaw.

    >>
    >> I see it as a flaw. A minor one. But a flaw nonetheless.
    >>
    >> ...
    >>
    >> Lets turn it around. Why would you think having a real boolean is NOT a
    >> good idea?

    >
    > I don't think that, and never suggested that I did. I don't have any


    You seemed a little "anti BOOL" in your previous reply and pretty much
    disagreed with the other poster and each point he made for having BOOL
    (not that I agreed with his points necessarily either).

    > strong feelings on the subject at all. I'm not sure that I consider
    > it's absence a flaw, but if it is it's a very minor one. I wouldn't


    Agreed.

    > object to its presence; its usefulness might outweigh the complexity
    > it would add, but by very little. Overall it doesn't much matter
    > either way in my opinion.


    What complexity would you be thinking of?

    >
    > The only real utility I can see in it is self-documentation of code,
    > but that's easily achieved by a programmer-defined typedef or even by
    > the name of the variable. It doesn't seem to warrant a fundamental
    > type.


    I would agree that there's no call for it now since its not there.

    >
    > I'm just puzzled why someone should see its absence as a MAJOR flaw,
    > to the extent that they can't conceive that the need for it didn't
    > occur to the inventors of the language. That's why I was asking.


    And I agree with you there. It would be nice though IMO. The underlying
    representation should not concern the programmer too much either.
    Richard, Nov 4, 2007
    #19
  20. AommiK

    Richard Guest

    santosh <> writes:

    > Richard wrote:
    >> "J. J. Farrell" <> writes:
    >>> On Nov 3, 10:56 pm, AommiK <> wrote:

    >
    >>>> OK. Some of you might refer to C99 and its _Bool (what's up with the
    >>>> uppercase 'B' anyway?) and the header you can include (apparently)
    >>>> to get a real "bool". This isn't my point, however -- it should have
    >>>> been there from the beginning.
    >>>
    >>> Why?

    >>
    >> Because C is a programming language that applies all sorts of rules on
    >> other types and a C program uses boolean decision making every other
    >> line or so ....

    >
    > And in C boolean decision making doesn't require a boolean type.


    Obviously. But that isn't the issue.

    >
    >>>> Char is a small int. We all know that. However, "char some_bool =
    >>>> 0;" simply feels wrong,
    >>>
    >>> Why?

    >>
    >> Because it's not a true "boolean".

    >
    > C defines zero as boolean false and any other value as boolean true, in
    > a boolean context. A specific boolean type isn't necessary except for
    > aesthetic purposes.


    Bingo! You've got it. Aesthetic purposes. Also for things like *cough*
    variable tagging and debugging it is useful.

    >
    >> When you see a char its not obvious
    >> fro the type that it's a binary indicator.

    >
    > That's what typedefs are for. Also the object's name should convey it's
    > intended boolean usage.


    So shall we get rid of ALL types and use typedefs?

    >
    >> Fairly obvious I would have thought.

    >
    > It's also fairly obvious that unlike languages like C#, C doesn't
    > require a boolean type; any value is interpreted as true or false
    > according to a simple rule.


    This is true of ANY language I have dealt with.

    if(x) .....



    >
    > Anyway the latest C standard _has_ mandated a boolean type, for whatever
    > it's worth.


    Aha. So not so silly and "useless" after all?

    >
    > However the OP was complaining about the lack of single bit boolean
    > types and the supposed wasted storage by using a char or int or
    > whatever.


    I would agree that is silly.

    >
    > Now, as far as I can see, there is no readily apparent reason against
    > implementing a bit type in C. However the fact that C conveniently
    > treats any integer value as either true or false, when in a boolean
    > context, combined with the probable loss of execution efficiency in
    > manipulating a bit type, meant that a specific boolean bit type was not
    > (and is not) felt as very essential to the language.
    >
    >> Lets turn it around. Why would you think having a real boolean is NOT
    >> a good idea?

    >
    > No one said it was not a good idea. Probable reasons were supplied for
    > why it was not built into the language from it's beginning. That does
    > not imply that boolean types are either good or bad.


    It is fairly clear to me that a boolean type would only make code
    cleaner. Would I use them? Probably not :-; I'm too entrenched in zero
    and non zero.
    Richard, Nov 4, 2007
    #20
    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:
    468
    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:
    371
    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:
    354
    Eliyahu Goldin
    Jul 7, 2003
  4. Georg Mayer
    Replies:
    1
    Views:
    331
    cosine... zero
    Jun 23, 2004
  5. Qi
    Replies:
    16
    Views:
    902
    Juha Nieminen
    Nov 26, 2011
Loading...

Share This Page