using char as boolean data type

Discussion in 'C Programming' started by Ramprasad A Padmanabhan, Sep 1, 2003.

  1. Hello all,

    On my linux box ( redhat 7.2 ), I have been using char as a boolean data
    type. In order to save on the number of bytes as compared to using int
    or short int.

    typedef char boolean;

    boolean x;
    x=1;
    .....


    if(x){
    /* x is true */
    } else {
    /* x is false */
    }
    }
    Is this usage of valid on all platforms. I will be happy If this will work
    on all linux distributions at least.

    Thanks
    Ram
     
    Ramprasad A Padmanabhan, Sep 1, 2003
    #1
    1. Advertising

  2. Ramprasad A Padmanabhan

    Derk Gwen Guest

    "Ramprasad A Padmanabhan" <> wrote:
    # Hello all,
    #
    # On my linux box ( redhat 7.2 ), I have been using char as a boolean data
    # type. In order to save on the number of bytes as compared to using int
    # or short int.
    #
    # typedef char boolean;
    #
    # boolean x;
    # x=1;
    # ....
    #
    #
    # if(x){
    # /* x is true */
    # } else {
    # /* x is false */
    # }
    # }
    # Is this usage of valid on all platforms.

    Yes.

    --
    Derk Gwen http://derkgwen.250free.com/html/index.html
    JUSTICE!
    Justice is dead.
     
    Derk Gwen, Sep 1, 2003
    #2
    1. Advertising

  3. "Ramprasad A Padmanabhan" <> wrote in
    <>:

    >typedef char boolean;
    >
    >boolean x;
    >x=1;
    >....
    >
    >
    >if(x){
    > /* x is true */
    >} else {
    > /* x is false */
    >}
    >}
    >Is this usage of valid on all platforms. I will be happy If this will work
    >on all linux distributions at least.
    >

    I cannot think of any problems with that code running on any conforming
    implementation I can think of.

    If I'm wrong, the c.l.c regulars will hopefully correct me. :)

    However, hiding a simple type behind a typename is considered bad style
    by some programmers - why not use char in the first place?

    Irrwahn

    --
    I wish life had a scroll-back buffer.
     
    Irrwahn Grausewitz, Sep 1, 2003
    #3
  4. Irrwahn Grausewitz wrote:
    > "Ramprasad A Padmanabhan" <> wrote in
    > <>:
    >
    >
    >>typedef char boolean;
    >>
    >>boolean x;
    >>x=1;
    >>....
    >>
    >>
    >>if(x){
    >> /* x is true */
    >>} else {
    >> /* x is false */
    >>}
    >>}
    >>Is this usage of valid on all platforms. I will be happy If this will work
    >>on all linux distributions at least.
    >>

    >
    > I cannot think of any problems with that code running on any conforming
    > implementation I can think of.
    >
    > If I'm wrong, the c.l.c regulars will hopefully correct me. :)
    >
    > However, hiding a simple type behind a typename is considered bad style
    > by some programmers - why not use char in the first place?
    >
    > Irrwahn
    >
    > --
    > I wish life had a scroll-back buffer.


    I typedef is just to avoid confusion.
    Like char x;
    x = 1;
    /* Though it works It seems logical only to have int types set to 1 */


    Ram
     
    news.cis.dfn.de, Sep 1, 2003
    #4
  5. Irrwahn Grausewitz wrote:
    > "Ramprasad A Padmanabhan" <> wrote in
    > <>:
    >
    >
    >>typedef char boolean;
    >>
    >>boolean x;
    >>x=1;
    >>....
    >>
    >>
    >>if(x){
    >> /* x is true */
    >>} else {
    >> /* x is false */
    >>}
    >>}
    >>Is this usage of valid on all platforms. I will be happy If this will work
    >>on all linux distributions at least.
    >>

    >
    > I cannot think of any problems with that code running on any conforming
    > implementation I can think of.
    >
    > If I'm wrong, the c.l.c regulars will hopefully correct me. :)
    >
    > However, hiding a simple type behind a typename is considered bad style
    > by some programmers - why not use char in the first place?
    >
    > Irrwahn
    >
    > --
    > I wish life had a scroll-back buffer.


    I typedef only to avoid confusion
    like
    char x = 1;
    /* Nothing wrong, but char x = any character is what is logical */


    Ram
     
    Ramprasad A Padmanabhan, Sep 1, 2003
    #5
  6. Ramprasad A Padmanabhan <> wrote in
    <bivkoq$dfvjr$-berlin.de>:

    >Irrwahn Grausewitz wrote:
    >> "Ramprasad A Padmanabhan" <> wrote in
    >> <>:
    >>
    >>
    >>>typedef char boolean;
    >>>
    >>>boolean x;
    >>>x=1;
    >>>....
    >>>
    >>>
    >>>if(x){
    >>> /* x is true */
    >>>} else {
    >>> /* x is false */
    >>>}
    >>>}
    >>>Is this usage of valid on all platforms. I will be happy If this will work
    >>>on all linux distributions at least.
    >>>

    >>
    >> I cannot think of any problems with that code running on any conforming
    >> implementation I can think of.
    >>
    >> If I'm wrong, the c.l.c regulars will hopefully correct me. :)
    >>
    >> However, hiding a simple type behind a typename is considered bad style
    >> by some programmers - why not use char in the first place?
    >>
    >> Irrwahn
    >>
    >> --
    >> I wish life had a scroll-back buffer.

    >
    >I typedef only to avoid confusion
    >like
    >char x = 1;
    >/* Nothing wrong, but char x = any character is what is logical */
    >

    This depends on your POV. Nothing is 'wrong' with one or the other -
    as you said.

    --
    It is not necessary to understand things
    in order to argue about them.
     
    Irrwahn Grausewitz, Sep 1, 2003
    #6
  7. > On my linux box ( redhat 7.2 ), I have been using char as a boolean data
    > type. In order to save on the number of bytes as compared to using int
    > or short int.
    >
    > typedef char boolean;
    >
    > boolean x;
    > x=1;
    > ....
    >
    >
    > if(x){
    > /* x is true */
    > } else {
    > /* x is false */
    > }
    > }
    > Is this usage of valid on all platforms. I will be happy If this will work
    > on all linux distributions at least.


    As others have said, it's okay. However, I infer from your query that
    you're looking to optimize code/size of executable, and that may not be
    happening as you think. Yes, using the char variable may use less of a
    _structure_data_, but it's entirely possible that the _code_generated_ to
    access it may be significantly more than if it were an int. This is
    because on many machines - and I can't say such for your hardware and
    Redhat Linux - the "native mode" data access is 32 bits. Hence the int
    default data type for boolean...
    Thus, while you're saving 16 bits of storage space, it's quite
    possible that the runtime code to access and manipulate the non-native
    data element is costing you much more. Also, you can't be sure of the
    _alignment_ it's getting, and you might not be saving any data space at
    all!
    The issue most likely is the _amount_ of space you're "saving" with
    this action: if you have thousands of these variables (or such), it's
    probably a "win"; if you just have a few of them, I'd bet you're having a
    "regressive improvement" with this choice. Another concern is the number
    of accesses you're applying: the extra code generated for the char data
    (versus int) is probably an item to consider.
    Bottom line: I'd have to need a good reason to do this sort of
    thing...
     
    Mike Copeland, Sep 1, 2003
    #7
  8. Mike Copeland wrote:
    >> On my linux box ( redhat 7.2 ), I have been using char as a boolean data
    >> type. In order to save on the number of bytes as compared to using int
    >> or short int.
    >>
    >>typedef char boolean;
    >>
    >>boolean x;
    >>x=1;
    >>....
    >>
    >>
    >>if(x){
    >> /* x is true */
    >>} else {
    >> /* x is false */
    >>}
    >>}
    >>Is this usage of valid on all platforms. I will be happy If this will work
    >>on all linux distributions at least.

    >
    >
    > As others have said, it's okay. However, I infer from your query that
    > you're looking to optimize code/size of executable, and that may not be
    > happening as you think. Yes, using the char variable may use less of a
    > _structure_data_, but it's entirely possible that the _code_generated_ to
    > access it may be significantly more than if it were an int. This is
    > because on many machines - and I can't say such for your hardware and
    > Redhat Linux - the "native mode" data access is 32 bits. Hence the int
    > default data type for boolean...
    > Thus, while you're saving 16 bits of storage space, it's quite
    > possible that the runtime code to access and manipulate the non-native
    > data element is costing you much more. Also, you can't be sure of the
    > _alignment_ it's getting, and you might not be saving any data space at
    > all!
    > The issue most likely is the _amount_ of space you're "saving" with
    > this action: if you have thousands of these variables (or such), it's
    > probably a "win"; if you just have a few of them, I'd bet you're having a
    > "regressive improvement" with this choice. Another concern is the number
    > of accesses you're applying: the extra code generated for the char data
    > (versus int) is probably an item to consider.
    > Bottom line: I'd have to need a good reason to do this sort of
    > thing...


    Right sir,

    I am using this script in a milter program that runs as a daemon
    listening on a socket. I use around 10-20 boolean flags in the entire
    daemon depending on what options are chosen. So Is it better to have
    boolean as int.

    Now these flags are a part of my structure and memory for it is
    'malloced' every instance so will mallocing ( and freeing in the end ) a
    larger structure take more resources ( CPU and memory ).

    My problem is the milter does take some load on the machine and I
    looking on to optimize the code.

    Thanks
    Ram
     
    Ramprasad A Padmanabhan, Sep 2, 2003
    #8
  9. Ramprasad A Padmanabhan

    pete Guest

    Ramprasad A Padmanabhan wrote:

    > >> In order to save on the number of bytes


    C:\Program Files\DevStudio\SharedIDE\bin\Debug>new
    Bit 0 of flags, is set.
    Bit 3 of flags, is set.
    Bit 4 of flags, is set.
    Bit 30 of flags, is set.

    /* BEGIN flags.c */

    #include <stdio.h>

    #define READ_LUBIT(F,N) (((F) & 1LU << (N)) != 0)
    #define SET_LUBIT(F,N) ((F) |= 1LU << (N))
    #define CLEAR_LUBIT(F,N) ((F) &= ~(1LU << (N)))
    #define FLIP_LUBIT(F,N) ((F) ^= 1LU << (N))

    #define MIN_BITS 32

    int main(void)
    {
    long unsigned flags = 0;
    int bit;

    SET_LUBIT(flags, 0);
    SET_LUBIT(flags, 3);
    SET_LUBIT(flags, 4);
    SET_LUBIT(flags, 30);

    for (bit = 0; bit != MIN_BITS; ++bit) {
    if (READ_LUBIT(flags, bit)) {
    printf("Bit %d of flags, is set.\n", bit);
    }
    }
    return 0;
    }

    /* END flags.c */



    --
    pete
     
    pete, Sep 2, 2003
    #9
  10. pete wrote:
    > Ramprasad A Padmanabhan wrote:
    >
    >
    >>>> In order to save on the number of bytes

    >
    >
    > C:\Program Files\DevStudio\SharedIDE\bin\Debug>new
    > Bit 0 of flags, is set.
    > Bit 3 of flags, is set.
    > Bit 4 of flags, is set.
    > Bit 30 of flags, is set.
    >
    > /* BEGIN flags.c */
    >
    > #include <stdio.h>
    >
    > #define READ_LUBIT(F,N) (((F) & 1LU << (N)) != 0)
    > #define SET_LUBIT(F,N) ((F) |= 1LU << (N))
    > #define CLEAR_LUBIT(F,N) ((F) &= ~(1LU << (N)))
    > #define FLIP_LUBIT(F,N) ((F) ^= 1LU << (N))
    >
    > #define MIN_BITS 32
    >
    > int main(void)
    > {
    > long unsigned flags = 0;
    > int bit;
    >
    > SET_LUBIT(flags, 0);
    > SET_LUBIT(flags, 3);
    > SET_LUBIT(flags, 4);
    > SET_LUBIT(flags, 30);
    >
    > for (bit = 0; bit != MIN_BITS; ++bit) {
    > if (READ_LUBIT(flags, bit)) {
    > printf("Bit %d of flags, is set.\n", bit);
    > }
    > }
    > return 0;
    > }
    >
    > /* END flags.c */
    >
    >
    >


    I dont want to use bits for boolean flags. I have just 10-20 flags not
    milllions that I will save any memory vis a vis the processing that will
    take
    I read on the same newsgroup that bitwise processing is waste of cpu and
    is unreasonable for a small number of variables

    Ram
     
    Ramprasad A Padmanabhan, Sep 3, 2003
    #10
  11. Ramprasad A Padmanabhan

    pete Guest

    Ramprasad A Padmanabhan wrote:
    >
    > pete wrote:
    > > Ramprasad A Padmanabhan wrote:


    > >>>> In order to save on the number of bytes


    > > #define READ_LUBIT(F,N) (((F) & 1LU << (N)) != 0)
    > > #define SET_LUBIT(F,N) ((F) |= 1LU << (N))


    > I dont want to use bits for boolean flags. I have just 10-20 flags not
    > milllions that I will save any memory vis a
    > vis the processing that will take I read on the same newsgroup that
    > bitwise processing is waste of cpu and
    > is unreasonable for a small number of variables


    You originally said that you were interested
    in the number of bytes.
    I see now that you are interested in saving bytes
    while considering speed.
    It is possible that char math may be slower than int math.

    You could do timing tests, but for your situation,
    I'm guessing that both the speed differences
    and the memory savings are entirely inconsequential
    regardless of whether you use int, char or bits
    for your boolean data.

    --
    pete
     
    pete, Sep 3, 2003
    #11
    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. luna
    Replies:
    1
    Views:
    6,856
  2. lovecreatesbeauty
    Replies:
    1
    Views:
    1,132
    Ian Collins
    May 9, 2006
  3. Les
    Replies:
    3
    Views:
    358
  4. J Leonard
    Replies:
    4
    Views:
    12,836
    Mark Space
    Jan 19, 2008
  5. Metre Meter
    Replies:
    7
    Views:
    431
    Metre Meter
    Aug 6, 2010
Loading...

Share This Page