Topic: How many byte in a bool?


Author: andys@thone.demon.co.uk (Andy Sawyer)
Date: Sat, 17 Dec 1994 21:00:05 +0000
Raw View
In article <787509516snz@wslint.demon.co.uk>
           Kevlin@wslint.demon.co.uk "Kevlin Henney" writes:

>
> No it won't. It will prevent you from compiling otherwise valid code:
>
>         enum bool { false, true };
>
>         bool b = x > y; // ERROR: LHS is enum bool, RHS is int
>
> Beware, young Skywalker, the preprocessor comes from the Dark Side of the
> Force. The following is a reasonable stopgap:
>
>         typedef int bool;
>         const bool false = 0;
>         const bool true  = 1;
>
> Hope this helps.
>

And now, completely over-the-top time:

typedef enum {
  false = 0,
  true  = 1
} bool_value;

class bool {
   bool_value m_value;
public:
   bool( bool_value init = false )
       { m_value = init; }
   bool( const bool& init )
       { m_value = init.m_value; }
   bool& operator=( const bool& assign )
       { m_value = assign.m_value;  return (*this); }
   operator int() const
       { return (m_value) ? 1 : 0; }
   bool& operator=( int val )
       { m_value = (val)?true:false; return (*this); }
   };


(P.S. This may not have all the semantics one would want, but you get the
idea...)

--
=============================================================================
| Andy Sawyer                Internet (Personal) : andys@thone.demon.co.uk  |
|                          Compu$erve (Business) : 100432,1713              |
=============================================================================
|The opinions expressed above are my own, but you are granted the right to  |
|use and freely distribute them. I accept no responsibility for any injury, |
|harm or damage arising from their use.                --   The Management. |
=============================================================================




Author: davisonj@en.ecn.purdue.edu (John M Davison)
Date: 18 Dec 1994 10:02:36 GMT
Raw View
        In article <34@ecsd.win.net> ecs@ecsd.win.net (Edward C. Schram)
writes:
>Any data (char, int, float, short) can be cast to an int...

        That is not necessarily true for a float.

        Followups to comp.lang.c++.
--
John Davison
Electronic Mail: davisonj@ecn.purdue.edu
WWW Home Page: <http://en.ecn.purdue.edu:20002/~davisonj/HomePage.html>




Author: jbuck@synopsys.com (Joe Buck)
Date: 15 Dec 1994 19:44:04 GMT
Raw View
leblanck@austin.ibm.com writes:
>  I've looked through the September copy of the C++ Working paper, and I can't
>find a definition for how many bytes are in a bool.  Since bool can be
>promoted to int, I'm assuming 4 bytes, but I need to have this confirmed
>somewhere.

The standard will not say (it also does not say that an int is 4 bytes).
This means that it is compiler-dependent.  sizeof (bool) will say what
your particular compiler uses.  For gcc-2.6.x the answer is 1 (one byte).

>  As we wait for bool to become part of the compiler, we are looking at
>using
> #define bool int
>But our code needs to save data in a persistent form usable between different
>compilers on different platforms.  We need to know how many bytes to assign
>to a bool.

This question is completely independent of what the compiler uses.  Since
bool can only hold "true" or "false", your persistent database only needs
to store one bit for each bool.  (It could use a byte instead, or four
bytes, if you prefer).


--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729




Author: ecs@ecsd.win.net (Edward C. Schram)
Date: Fri, 16 Dec 1994 14:07:32 GMT
Raw View
> In article <D0poKB.4nCI@austin.ibm.com>, Karalee LeBlanc
>  I've looked through the September copy of the C++ Working paper, and I can't
>find a definition for how many bytes are in a bool.  Since bool can be
>promoted to int, I'm assuming 4 bytes, but I need to have this confirmed
>somewhere.
>  As we wait for bool to become part of the compiler, we are looking at
>using
> #define bool int
>But our code needs to save data in a persistent form usable between different
>compilers on different platforms.  We need to know how many bytes to assign
>to a bool.
>  I really hope bool doesn't end up being like a "long double" which has
>different byte counts on different compilers.

Is there currently a system where even Ints are the same across
platforms?  The z80 has 2 byte ints, the 68000 has 4 byte ints and
the TMS320 has 4 byte chars.

For all of our systems we define:
typedef char byte - single byte data
typedef unsigned char ubyte
typedef short word - or whatever it
takes to get 2 bytes  typedef unsigned short uword
typedef int lword - 4 byte data
typedef unsigned int ulword

typedef ubyte bool
typedef ubyte boole
typedef enum
{
    OFF = 0,
    ON
} boolean;

This code added to the sysdef.h file for all systems allows us to
track what data is being written at what time.  For crossing
between 68k, intel, and zilog systems we have routines that swap
bytes into little and big endian formats.

Any data (char, int, float, short) can be cast to an int so it
doesn't matter what size you pick.  Make the choice based on
memory usage and optimization needs. My recommendation is that if
you are crossing platforms, make bool a byte to avoid big/little
endian problems, and always define it as above.

ecs@ecsd.win.net





Author: matt@physics10.berkeley.edu (Matt Austern)
Date: 15 Dec 1994 00:41:38 GMT
Raw View
In article <D0poKB.4nCI@austin.ibm.com> leblanck@austin.ibm.com (Karalee LeBlanc) writes:

> But our code needs to save data in a persistent form usable between different
> compilers on different platforms.  We need to know how many bytes to assign
> to a bool.
>   I really hope bool doesn't end up being like a "long double" which has
> different byte counts on different compilers.

Bool will end up with a different byte count on different compilers.
Every other data type in C++ has that property, after all; why should
bool be any different?

Neither C nor C++ specifies the number of bytes in a data type.  Nor,
for that matter, does either language specify the number of bits in a
byte.  This is as it should be.  Machine architectures can and do
vary: if the C++ standard mandated that (say) an int had to be a
36-bit data type, then it would be impossible to implement C++ on
hardware that didn't have a 36-bit word.

In practice, I should think that implementors would represent a bool
with the smallest word that can be addressed efficiently.  (In
principle, after all, you only need a single bit.)  On most of today's
architectures, that'll probably mean that a bool will be either 8 or
32 bits.
--

                               --matt




Author: alan@rcp.co.uk (Alan Stokes)
Date: Thu, 15 Dec 94 12:55:26 GMT
Raw View
In <D0poKB.4nCI@austin.ibm.com> leblanck@austin.ibm.com (Karalee LeBlanc) writes:
>  I've looked through the September copy of the C++ Working paper, and I can't
>find a definition for how many bytes are in a bool.

sizeof(bool)

>  Since bool can be
>promoted to int, I'm assuming 4 bytes, but I need to have this confirmed
>somewhere.

int is not necessarily 4 bytes. It is at least 16 bits, but that's all you
can say about it.

>  As we wait for bool to become part of the compiler, we are looking at
>using
> #define bool int

Seems reasonable to me, although an enum might give you better type checking.

>But our code needs to save data in a persistent form usable between different
>compilers on different platforms.  We need to know how many bytes to assign
>to a bool.

Non sequitur. Things don't work that way. You'll have to define your own
format and read and write it in a platform independent way (which basically
means you have to transform to & from a stream of chars).

>  I really hope bool doesn't end up being like a "long double" which has
>different byte counts on different compilers.

All the types in C++ can have different byte counts on different compilers.
So don't assume they're the same and write your code properly.


--
Alan Stokes (alan@rcp.co.uk)
Richards Computer Products Ltd
Didcot, UK




Author: kevlin@wslint.demon.co.uk (Kevlin Henney)
Date: Thu, 15 Dec 1994 16:38:36 +0000
Raw View
In article <+yD8uAcBBh107h@rcp.co.uk> alan@rcp.co.uk "Alan Stokes" writes:

>In <D0poKB.4nCI@austin.ibm.com> leblanck@austin.ibm.com (Karalee LeBlanc)
> writes:
>>  As we wait for bool to become part of the compiler, we are looking at
>>using
>> #define bool int
>
>Seems reasonable to me, although an enum might give you better type checking.

No it won't. It will prevent you from compiling otherwise valid code:

 enum bool { false, true };

 bool b = x > y; // ERROR: LHS is enum bool, RHS is int

Beware, young Skywalker, the preprocessor comes from the Dark Side of the
Force. The following is a reasonable stopgap:

 typedef int bool;
 const bool false = 0;
 const bool true  = 1;

Hope this helps.

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+




Author: leblanck@austin.ibm.com (Karalee LeBlanc)
Date: Mon, 12 Dec 1994 18:55:23 GMT
Raw View
  I've looked through the September copy of the C++ Working paper, and I can't
find a definition for how many bytes are in a bool.  Since bool can be
promoted to int, I'm assuming 4 bytes, but I need to have this confirmed
somewhere.
  As we wait for bool to become part of the compiler, we are looking at
using
 #define bool int
But our code needs to save data in a persistent form usable between different
compilers on different platforms.  We need to know how many bytes to assign
to a bool.
  I really hope bool doesn't end up being like a "long double" which has
different byte counts on different compilers.
--
-----------------------------------------------------
Karalee LeBlanc
Dept 908, Bld 008, Room 7D050
Austin, Tx.  Tie/Phone 678/838-3409