RBREMER@future-gate.com   (Ronny Bremer) writes:

>In <31DCD53D.2FBA@isis.co.za>, William Dicks <wd@isis.co.za> writes:

>>I'm interested in knowing why in the new proposed standard a bool is
>>defined as an int. Can it not be defined as a char?

>An int is by definition excactly the size of a register,

No, that is not true. The size of an int is implementation-defined,
and can be any size not less thatn 16 bits. The intent is for an int
to be the "natural size" for an integer variable on the hardware.

>
>Everything smaller than an int (for example a
>char) is internaly treated as an int except if it is part of a structure, class or
>union with structure packing set to on.

That is also not true. The char and short types can be promoted to
type int, but they are nevertheless separate types. They are typically
smaller than an int, but need not be. "Structure packing" may be a feature
of some comilers, but is not part of the C or C++ language definitions.
(And this is comp.STD.c++, after all.)

Finally, the original posted was misinformed if he though bool was
defined as int. That is also not the case. The size of type bool is
implementation-defined. A bool value may be implicitly converted to any
numerical type (char, int, double, etc) but is a separate type.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <31DCD53D.2FBA@isis.co.za> William Dicks <wd@isis.co.za>
writes:

|> I'm interested in knowing why in the new proposed standard a bool is
|> defined as an int. Can it not be defined as a char?

In the versions of the draft that I've seen, bool is defined as a
totally new integral type.  I think it would even be legal (although
probably not to intelligent) for an implementation to give it a size
different from all existing integral types.

I expect, of course, that most real implementation will make it the
same as either an int or a char, depending on the whim of the
implementor (and what works best on his hardware).
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I'm interested in knowing why in the new proposed standard a bool is
defined as an int. Can it not be defined as a char?

--
William G Dicks (Systems Analyst - C++ & Theology Graduate) wd@isis.co.za
ISIS Information Systems
Gauteng
South Africa
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <31DCD53D.2FBA@isis.co.za>, William Dicks <wd@isis.co.za> writes:

>I'm interested in knowing why in the new proposed standard a bool is
>defined as an int. Can it not be defined as a char?

An int is by definition excactly the size of a register, meaning a value can be
held in the fastest storage area. Everything smaller than an int (for example a
char) is internaly treated as an int except if it is part of a structure, class or
union with structure packing set to on.
Most of the machines available today are optimized for using int's. So it is the
most preferrable solution.

If you want to assign it to a char use something like:

bool aBool;
char cBool;

cBool = (aBool == true);

Ronny


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

William Dicks <wd@isis.co.za> wrote:
: I'm interested in knowing why in the new proposed standard a bool is
: defined as an int. Can it not be defined as a char?
It's most-likely because making it a 'char' proved to be too troublesome
interfacing with C library routines that use bool as int (or it could
be to avoid forcing promotions).

btw, I got a report that gcc 2.7.2 (on Linux) is using bool as char
(which is not right).

--
Thomas E. Dickey
dickey@clark.net
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

dickey@clark.net (T.E.Dickey) writes:

>William Dicks <wd@isis.co.za> wrote:
>: I'm interested in knowing why in the new proposed standard a bool is
>: defined as an int. Can it not be defined as a char?
>It's most-likely because making it a 'char' proved to be too troublesome
>interfacing with C library routines that use bool as int (or it could
>be to avoid forcing promotions).
>
>btw, I got a report that gcc 2.7.2 (on Linux) is using bool as char
>(which is not right).

Whoa, hold it --- I think we need to inject some facts into this discussion.

The committee's draft working paper does not define `bool' as `int',
and nor does it define `bool' as `char'.  Rather, all three are
distinct integral types.  The draft working paper does not specify the
size of either `int' or `bool'.  (`char' is defined to be one byte, hence
you can be assured that `sizeof(char) == 1' is true, but the size of a
byte is not specified --- it may be any number of bits >= 7.)
An implementation is allowed to use any number of bytes to hold a `bool';
the number chosen will be whatever the implementors think will be most
useful (based on efficiency or any other reason).

GNU C++ uses different sizes for `bool' on different architectures --
on CISCy architectures which can manipulates bytes at least as
efficiently as words, `bool' is defined as one byte (the same size as
`char'), but on RISCy architectures which can manipulate words more
easily than bytes, `bool' is defined as the size of a machine word.
For example, on the Alpha, GNU C++ defines an `int' to be 4 bytes (32 bits),
but `bool' is eight bytes (64 bits).

This behaviour of GNU C++ does conform to the C++ committee's draft
working paper.

Although the C++ standard doesn't dictate efficiency, I think many
C++ compilers may adopt a similar approach to that of GNU C++:
choosing a size for `bool' that maximizes time efficiency without
much regard for space efficiency.  I would advise programmers who
need to ensure space efficiency to use bitfields.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Ronny Bremer wrote:
>
> In <31DCD53D.2FBA@isis.co.za>, William Dicks <wd@isis.co.za> writes:
>
> >I'm interested in knowing why in the new proposed standard a bool is
> >defined as an int. Can it not be defined as a char?[..]
> Most of the machines available today are optimized for using int's.
> So it is the most preferrable solution.

I would have thought that this assumption is wrong. Most machines
handle chars, albeit by accident, at least as fast as an int within the
context of a single instruction. However, when processor pipelining and
memory usage (cache) is taken into consideration then char has to be
faster - no?

Yours, waiting-to-be-correctedly...

--
Keith Whittingham
Email: wgk@zurich.ibm.com
(H) 111 Seebahnstrasse, 8003 Zurich CH. Tel: Int+41 1 461-6713
(W) Int+41 1 724-8569, Fax: (W) Int+41 1 710-3608
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

RBREMER@future-gate.com   (Ronny Bremer) writes:

> An int is by definition excactly the size of a register, meaning a
> value can be held in the fastest storage area.

That's not correct.  The size of an int is implementation-defined;
there is no requirement that it be exactly the size of a register.
(What if the machine doesn't *have* any registers?  Or what if all the
registers it has are all different sizes?)
Indeed, it is quite common for C and C++ compilers on the latest 64-bit
machines to define `int' as only 32 bits, even though registers are 64 bits.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Keith Whittingham <wgk@zurich.ibm.com> writes:

>Ronny Bremer wrote:
>>
>> Most of the machines available today are optimized for using int's.
[...]
>I would have thought that this assumption is wrong. Most machines
>handle chars, albeit by accident, at least as fast as an int within the
>context of a single instruction. However, when processor pipelining and
>memory usage (cache) is taken into consideration then char has to be
>faster - no?

I believe not, although detailed discussion of this point should
probably be left to comp.arch.  But even if that were the case, the C++
standard should ideally not impose any (further) restrictions on future
architectures.  The C++ committee should strive to devise a standard
which can be efficiently implemented even on architectures which have
not yet been designed.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

William Dicks wrote:
>
> I'm interested in knowing why in the new proposed standard a bool is
> defined as an int. Can it not be defined as a char?
>
The standard merely says that "bool" is a signed integral type. Borland
5.0, for instance, allocates one byte to a bool. When it's used in an
arithmetic expression, it's promoted to an int, just like a char would
be, but in memory it's just a byte. It's considered signed, even though
its value is always either 0 or 1, so that it won't coerce the result of
an enclosing arithmetic expression to unsigned, I presume.

--

Ciao,
Paul D. DeRocco
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4rre9e$msc@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> and nor does it define `bool' as `char'.  Rather, all three are
|> distinct integral types.  The draft working paper does not specify the
|> size of either `int' or `bool'.  (`char' is defined to be one byte, hence
|> you can be assured that `sizeof(char) == 1' is true, but the size of a
|> byte is not specified --- it may be any number of bits >= 7.)

I'd be interested in seeing a conforming implementation with only 7
bits in a byte.  It must have some very clever technology in order to
ensure that UCHAR_MAX >= 255 in only 7 bits.  Or did you mean bits > 7?

|> An implementation is allowed to use any number of bytes to hold a `bool';
|> the number chosen will be whatever the implementors think will be most
|> useful (based on efficiency or any other reason).

|> GNU C++ uses different sizes for `bool' on different architectures --
|> on CISCy architectures which can manipulates bytes at least as
|> efficiently as words, `bool' is defined as one byte (the same size as
|> `char'), but on RISCy architectures which can manipulate words more
|> easily than bytes, `bool' is defined as the size of a machine word.
|> For example, on the Alpha, GNU C++ defines an `int' to be 4 bytes
|> (32 bits), but `bool' is eight bytes (64 bits).

Bool bigger than int!  Definitly legal, but I would have some questions
concerning quality of implementation.  If 64 bit accesses are that much
faster than 32, why aren't int's 64 bits too?

|> This behaviour of GNU C++ does conform to the C++ committee's draft
|> working paper.

|> Although the C++ standard doesn't dictate efficiency, I think many
|> C++ compilers may adopt a similar approach to that of GNU C++:
|> choosing a size for `bool' that maximizes time efficiency without
|> much regard for space efficiency.  I would advise programmers who
|> need to ensure space efficiency to use bitfields.

Especially when they need arrays of bool, and pointers to bool:-).

Seriously, when space is a criteria, I would use an array of unsigned
char, with bit masks, etc.  But I think that vector< bool > is supposed
to handle this in an optimal way.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|> (`char' is defined to be one byte, hence
>|> you can be assured that `sizeof(char) == 1' is true, but the size of a
>|> byte is not specified --- it may be any number of bits >= 7.)
>
>I'd be interested in seeing a conforming implementation with only 7
>bits in a byte.  It must have some very clever technology in order to
>ensure that UCHAR_MAX >= 255 in only 7 bits.  Or did you mean bits > 7?

Oops, yes I meant bits > 7.  Thanks for the correction.

>|> For example, on the Alpha, GNU C++ defines an `int' to be 4 bytes
>|> (32 bits), but `bool' is eight bytes (64 bits).
>
>Bool bigger than int!  Definitly legal, but I would have some questions
>concerning quality of implementation.  If 64 bit accesses are that much
>faster than 32, why aren't int's 64 bits too?

Compatibility with the system C compiler, I believe.
As for the system C compiler's choice of 32 bits, I suspect that having
a standard type for every power-of-two size of integer from 8 to 64
bits -- char = 8, short = 16, int = 32, long = 64 -- was an important
factor; space efficiency of existing programs must also have been
an important consideration.

Unfortunately the simple concept in C that `int' should be the "most
efficient" integral type with >= 16 bits doesn't work as well as might
be imagined, because different sizes may be more efficient for
different applications, depending on whether space- or time-efficiency
is more important, or depending on the relative frequency of
multiplications versus additions, or a number of other factors.
Furthermore, an even more difficult problem is that application binary
interfaces (ABIs) must specify the size of the basic types such as
`int', but a single ABI should be able to span a whole family of
different chips sharing the same basic architecture, and the "most
efficient" integral type may well be different on different chips in
the same family.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <<31DCD53D.2FBA@isis.co.za>>,
William Dicks <wd@isis.co.za> wrote:

>I'm interested in knowing why in the new proposed standard a bool is
>defined as an int. Can it not be defined as a char?

 I believe it's defined as an "integer type", which means it's in the
same category as and int, char, long etc.  without tying an actual
size to it.

 However, if the standard does say that sizeof(bool) == sizeof(int) (I
don't have a copy of the draft handy to check), I assume it's because
an int is supposed to be the data size that the peocessor can handle
most efficiently.

 [Moderator's note: the draft does _not_ say that
 sizeof(bool) == sizeof(int).  -fjh.]

       Truth,
       James
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4rre9e$msc@mulga.cs.mu.OZ.AU>, fjh@murlibobo.cs.mu.OZ.AU
says...
[ ... ]

> Although the C++ standard doesn't dictate efficiency, I think many
> C++ compilers may adopt a similar approach to that of GNU C++:
> choosing a size for `bool' that maximizes time efficiency without
> much regard for space efficiency.  I would advise programmers who
> need to ensure space efficiency to use bitfields.

Perhaps C++ should follow the route Pascal took years ago, with a
`packed' keyword and `pack' and `unpack' as standard functions.

(No, I won't mind if people laugh at the suggestion - even if the
timing were right for further extensions to the language, I certainly
wouldn't propose it formally.)
--
    Later,
    Jerry.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <MPLANET.31e4b0fdjcoffin989706@news.rmi.net>, jcoffin@taeus.com
(Jerry Coffin) wrote:

> Perhaps C++ should follow the route Pascal took years ago, with a
> `packed' keyword and `pack' and `unpack' as standard functions.
>
> (No, I won't mind if people laugh at the suggestion - even if the
> timing were right for further extensions to the language, I certainly
> wouldn't propose it formally.)

Sounds like you could create a C++ class for that. If you pratice good
encapsulation, you should have access to object data only through methods,
anyway. Then, when an object is packed, the methods would go through a
little more work to unpack the information to access it.

You could either provide a state member that indicates whether the object
is packed, or use a scheme where there are packed and unpacked subclasses
of some class and the Pack() and Unpack() methods essentially perform a
cast between the two classes.

For a rough example of this, take a look at the STL bit vector class (I
can't remember the exact name). It efficiently packs booleans into bit
"arrays". Now, imagine a class BooleanVector that has subclasses
PackedBooleanVector and UnpackedBooleanVector. The class
PackedBooleanVector would behave exactly as the existing STL bit vector,
but UnpackedBooleanVector would store the booleans in bytes or words, or
what have you.

....................................................................
Chris Page
Software Wrangler                               mailto:page@best.com
Claris Corporation                 http:www.best.com/~page/home.html
....................................................................
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]