# Size of bool unspecified: why?

Discussion in 'C++' started by MikeP, Jul 16, 2011.

1. ### MikePGuest

Why is the size of 'bool' unspecified? That makes bools pretty useless as
struct members. If one foregoes bools in structs, why not then specify
that bools should be the size of int and thereby likely to be fast to
pass to and from functions? (Is it less efficient to pass
less-than-word-size integers because then they have to be sign-extended
or zero-extended, or any other reason?)

MikeP, Jul 16, 2011

2. ### MikePGuest

Robert Wessel wrote:
> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <> wrote:
>
>> Why is the size of 'bool' unspecified? That makes bools pretty
>> useless as struct members. If one foregoes bools in structs, why not
>> then specify that bools should be the size of int and thereby likely
>> to be fast to pass to and from functions? (Is it less efficient to
>> pass less-than-word-size integers because then they have to be
>> sign-extended or zero-extended, or any other reason?)

>
>
> How does the unspecified size of bool make them useless in structs?

How doesn't it?

> The size of ints is also unspecified*, and I use ints in structures
> all the time.

Well, there are structs, and then there are structs.

>
> *except being at least 16 bits - although clearly a minimum exists for
> bools as well.

On VC++ 2010 it is one byte. In some version long ago, it was the size of
int, but probably because that was before the standard declared it could
be unspecified. Let's play a game ("Would you like to play a game? How
about a nice game of chess?" ). If you could have your bool and eat it
too... let me rephrase that: if you could create your own boolean type,
describe it. Describe 2 if you want to: one for C++, and one for your
ideal language that does not yet exist.

MikeP, Jul 17, 2011

3. ### Ian CollinsGuest

On 07/17/11 05:07 PM, MikeP wrote:
> Robert Wessel wrote:
>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP"<> wrote:
>>
>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>> useless as struct members. If one foregoes bools in structs, why not
>>> then specify that bools should be the size of int and thereby likely
>>> to be fast to pass to and from functions? (Is it less efficient to
>>> pass less-than-word-size integers because then they have to be
>>> sign-extended or zero-extended, or any other reason?)

>>
>>
>> How does the unspecified size of bool make them useless in structs?

>
> How doesn't it?

It's never bothered me. Why would the size be important? If size and
alignment is important to an environment, the sizes will be specified.

--
Ian Collins

Ian Collins, Jul 17, 2011
4. ### MikePGuest

Ian Collins wrote:
> On 07/17/11 05:07 PM, MikeP wrote:
>> Robert Wessel wrote:
>>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP"<> wrote:
>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>> useless as struct members. If one foregoes bools in structs, why
>>>> not then specify that bools should be the size of int and thereby
>>>> likely to be fast to pass to and from functions? (Is it less
>>>> efficient to pass less-than-word-size integers because then they
>>>> have to be sign-extended or zero-extended, or any other reason?)
>>>
>>>
>>> How does the unspecified size of bool make them useless in structs?

>>
>> How doesn't it?

>
> It's never bothered me. Why would the size be important? If size and
> alignment is important to an environment, the sizes will be specified.

MikeP, Jul 17, 2011
5. ### MikePGuest

Robert Wessel wrote:
[whatever the **** he said]

I am not a warrior.

Someone tell Eric C. Weis to GET THE **** OUT OF MY FACE.

> On Sun, 17 Jul 2011 00:07:19 -0500, "MikeP" <> wrote:
>
>> Robert Wessel wrote:
>>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <>
>>> wrote:
>>>
>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>> useless as struct members. If one foregoes bools in structs, why
>>>> not then specify that bools should be the size of int and thereby
>>>> likely to be fast to pass to and from functions? (Is it less
>>>> efficient to pass less-than-word-size integers because then they
>>>> have to be sign-extended or zero-extended, or any other reason?)
>>>
>>>
>>> How does the unspecified size of bool make them useless in structs?

>>
>> How doesn't it?
>>
>>> The size of ints is also unspecified*, and I use ints in structures
>>> all the time.

>
>
> I give up - how does it? I've used bools in structs. Seemed to work
> just fine. I've used bit fields in structs too, and they're also
> undefined as to what they're actually stored in. That also seemed to
> work.
>
> Both of those, the size of bools, and the storage of bit fields, are
> defined for a particular implementation.
>
>
>> Well, there are structs, and then there are structs.

>
>
> True, but less than informative. I personally find structs containing
> long doubles to be particular impressive - now *those* are *structs*!
>
>
>>>
>>> *except being at least 16 bits - although clearly a minimum exists
>>> for bools as well.

>>
>> On VC++ 2010 it is one byte. In some version long ago, it was the
>> size of int, but probably because that was before the standard
>> declared it could be unspecified. Let's play a game ("Would you like
>> to play a game? How about a nice game of chess?" ). If you could
>> have your bool and eat it too... let me rephrase that: if you could
>> create your own boolean type, describe it. Describe 2 if you want
>> to: one for C++, and one for your ideal language that does not yet
>> exist.

>
>
> Are you talking about interfacing code compiled with different
> versions of the compiler? As a general rule, you shouldn't be mixing
> code from different versions of a C compiler (or equivalently,
> invocations of the C compiler with certain different options), unless
> you restrict yourself to things specified by the system ABI or some
> other ABI that's specified to be valid between the versions in
> question. There are plenty of potential (and allowed)
> incompatibilities in that scenario. Everything from padding to
> alignment, to the storage of bit fields, to the size of ints, to the
> signedness of chars, to calling convention, to name decoration, to the
> format of vtables, to...
>
> Errr... and my "ideal" boolean stores one of two values, and I care
> little about its internal representation. I'd probably pick something
> the size of an int (or whatever my languages equivalent for that is)
> if I cared about speed, a byte or a bit if I cared more about space.
>
> And I really don't mind if you reply to Ian before I reply to you.
> Really I don't.

MikeP, Jul 17, 2011
6. ### MikePGuest

Robert Wessel wrote:

I meant PUH LEEEEZE! (And go fuk yer mom).

MikeP, Jul 17, 2011
7. ### MikePGuest

Robert Wessel wrote:
> On Sun, 17 Jul 2011 03:02:15 -0500, "MikeP" <> wrote:
>
>> Robert Wessel wrote:
>> [whatever the **** he said]
>>
>> I am not a warrior.
>>
>> Someone tell Eric C. Weis to GET THE **** OUT OF MY FACE.

>
>
>
>
>>> On Sun, 17 Jul 2011 00:07:19 -0500, "MikeP" <>
>>> wrote:
>>>
>>>> Robert Wessel wrote:
>>>>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <>
>>>>> wrote:
>>>>>
>>>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>>>> useless as struct members. If one foregoes bools in structs, why
>>>>>> not then specify that bools should be the size of int and thereby
>>>>>> likely to be fast to pass to and from functions? (Is it less
>>>>>> efficient to pass less-than-word-size integers because then they
>>>>>> have to be sign-extended or zero-extended, or any other reason?)
>>>>>
>>>>>
>>>>> How does the unspecified size of bool make them useless in
>>>>> structs?
>>>>
>>>> How doesn't it?
>>>>
>>>>> The size of ints is also unspecified*, and I use ints in
>>>>> structures all the time.
>>>
>>>
>>> I give up - how does it? I've used bools in structs. Seemed to
>>> work just fine. I've used bit fields in structs too, and they're
>>> also undefined as to what they're actually stored in. That also
>>> seemed to work.
>>>
>>> Both of those, the size of bools, and the storage of bit fields, are
>>> defined for a particular implementation.
>>>
>>>
>>>> Well, there are structs, and then there are structs.
>>>
>>>
>>> True, but less than informative. I personally find structs
>>> containing long doubles to be particular impressive - now *those*
>>> are *structs*!
>>>
>>>
>>>>>
>>>>> *except being at least 16 bits - although clearly a minimum exists
>>>>> for bools as well.
>>>>
>>>> On VC++ 2010 it is one byte. In some version long ago, it was the
>>>> size of int, but probably because that was before the standard
>>>> declared it could be unspecified. Let's play a game ("Would you
>>>> like to play a game? How about a nice game of chess?" ). If you
>>>> could have your bool and eat it too... let me rephrase that: if
>>>> you could create your own boolean type, describe it. Describe 2 if
>>>> you want to: one for C++, and one for your ideal language that
>>>> does not yet exist.
>>>
>>>
>>> Are you talking about interfacing code compiled with different
>>> versions of the compiler? As a general rule, you shouldn't be
>>> mixing code from different versions of a C compiler (or
>>> equivalently, invocations of the C compiler with certain different
>>> options), unless you restrict yourself to things specified by the
>>> system ABI or some other ABI that's specified to be valid between
>>> the versions in question. There are plenty of potential (and
>>> allowed) incompatibilities in that scenario. Everything from
>>> padding to alignment, to the storage of bit fields, to the size of
>>> ints, to the signedness of chars, to calling convention, to name
>>> decoration, to the format of vtables, to...
>>>
>>> Errr... and my "ideal" boolean stores one of two values, and I care
>>> little about its internal representation. I'd probably pick
>>> something the size of an int (or whatever my languages equivalent
>>> for that is) if I cared about speed, a byte or a bit if I cared
>>>
>>> And I really don't mind if you reply to Ian before I reply to you.
>>> Really I don't.

And why don't you get the **** out of my face?

MikeP, Jul 17, 2011
8. ### Juha NieminenGuest

MikeP <> wrote:
> Why is the size of 'bool' unspecified?

Probably for the same reason that the size of *any* basic type (with
the exception of char) is unspecified?

Juha Nieminen, Jul 17, 2011
9. ### JamesGuest

"MikeP" <> wrote in message
news:ivue3c\$fp4\$...
>> Robert Wessel wrote:
>> On Sun, 17 Jul 2011 03:02:15 -0500, "MikeP" <> wrote:

[...]
>
> And why don't you get the **** out of my face?

Are you really that moronic?

Wow! :^)

James, Jul 18, 2011
10. ### MikePGuest

James wrote:
> "MikeP" <> wrote in message
> news:ivue3c\$fp4\$...
>>> Robert Wessel wrote:
>>> On Sun, 17 Jul 2011 03:02:15 -0500, "MikeP" <>
>>> wrote: [...]

>>
>> And why don't you get the **** out of my face?

>
> Are you really that moronic?
>
> Wow! :^)

I have my moments\

MikeP, Jul 18, 2011
11. ### MikePGuest

Juha Nieminen wrote:
> MikeP <> wrote:
>> Why is the size of 'bool' unspecified?

>
> Probably for the same reason that the size of *any* basic type (with
> the exception of char) is unspecified?'

MikeP, Jul 18, 2011
12. ### JamesGuest

"MikeP" <> wrote in message
news:j016je\$7s1\$...
> James wrote:
>> "MikeP" <> wrote in message
>> news:ivue3c\$fp4\$...
>>>> Robert Wessel wrote:
>>>> On Sun, 17 Jul 2011 03:02:15 -0500, "MikeP" <>
>>>> wrote: [...]
>>>
>>> And why don't you get the **** out of my face?

>>
>> Are you really that moronic?
>>
>> Wow! :^)

>
> I have my moments\

;^)

James, Jul 19, 2011
13. ### Ian CollinsGuest

On 07/18/11 11:49 PM, MikeP wrote:
> James wrote:
>>
>> Are you really that moronic?
>>
>> Wow! :^)

>
> I have my moments\

Some moments are best enjoyed in private.

--
Ian Collins

Ian Collins, Jul 19, 2011
14. ### MikePGuest

Ian Collins wrote:
> On 07/18/11 11:49 PM, MikeP wrote:
>> James wrote:
>>>
>>> Are you really that moronic?
>>>
>>> Wow! :^)

>>
>> I have my moments\

>
> Some moments are best enjoyed in private.

When one Mr. John Daniels invites you to have a few, well, he can be
quite influential (hard to say no to a friend that has always been there
for you), especially if the bars closed way to early (3 AM?). Anyway, I
didn't type that (John did, and he probably thought it would be absurdly
funny too, who knows).

MikeP, Jul 20, 2011
15. ### James KanzeGuest

On Jul 16, 6:02 pm, BGB <> wrote:
> On 7/16/2011 3:33 AM, MikeP wrote:

> > Why is the size of 'bool' unspecified? That makes bools pretty useless as
> > struct members. If one foregoes bools in structs, why not then specify
> > that bools should be the size of int and thereby likely to be fast to
> > pass to and from functions? (Is it less efficient to pass
> > less-than-word-size integers because then they have to be sign-extended
> > or zero-extended, or any other reason?)

First, is size of bool unspecified? Or just implementation
defined? The size of all types is implementation defined (with
a minimum size).

And I don't see the issue with regards to structs.

> IIRC, many compilers default to making them the same size as char, or a
> single byte. this tends to be most convinient as, bigger, and they are
> just wasting space, and smaller, as messing with bits is awkward and
> costly (as well as compromising their direct addressability, ...).

A bool is required to be addressable; sizeof(bool) is also
required to return an integral value. So a bool can't be
smaller than a char. On a byte addressable machine, there's
also no reason to make them bigger, and I would expect them to
usually be the same as a char. On a word addressable machine,
accessing single bytes may be more expensive than accessing a
complete word, and there are arguments both ways.

> as for passing smaller integer types, these tend to be promoted
> internally to the smallest convinient size (namely, int) anyways, and on
> common architectures this doesn't add any real cost (both x86 and ARM
> have instructions to load a byte from memory with sign or zero extension).

Depending on the context: on many machines, it may be just as
fast to simply pass an int, with garbage in all but the low/high
order byte (depending on endianness). The garbage doesn't
matter, of course, because the callee won't ever look at it.

> granted, yes, this does in-fact still depend on the compiler
> though.

As does just about everything else.

--
James Kanze

James Kanze, Jul 20, 2011
16. ### James KanzeGuest

On Jul 18, 12:50 pm, "MikeP" <> wrote:
> Juha Nieminen wrote:
> > MikeP <> wrote:
> >> Why is the size of 'bool' unspecified?

> > Probably for the same reason that the size of *any* basic type (with
> > the exception of char) is unspecified?'

Or enough maturity to recognize that not all machines are PC's.

--
James Kanze

James Kanze, Jul 20, 2011
17. ### JBarleycornGuest

James Kanze wrote:
> On Jul 16, 6:02 pm, BGB <> wrote:
>> On 7/16/2011 3:33 AM, MikeP wrote:

>
>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>> useless as struct members. If one foregoes bools in structs, why
>>> not then specify that bools should be the size of int and thereby
>>> likely to be fast to pass to and from functions? (Is it less
>>> efficient to pass less-than-word-size integers because then they
>>> have to be sign-extended or zero-extended, or any other reason?)

>
> First, is size of bool unspecified? Or just implementation
> defined?

Isn't that the same thing?

> The size of all types is implementation defined (with
> a minimum size).
>
> And I don't see the issue with regards to structs.

C compatibility where layout, then, matters? Data transfer/storage.

>
>> IIRC, many compilers default to making them the same size as char,
>> or a single byte. this tends to be most convinient as, bigger, and
>> they are just wasting space, and smaller, as messing with bits is
>> awkward and costly (as well as compromising their direct

>
> A bool is required to be addressable; sizeof(bool) is also
> required to return an integral value. So a bool can't be
> smaller than a char. On a byte addressable machine, there's
> also no reason to make them bigger,

Efficiency?

> and I would expect them to
> usually be the same as a char. On a word addressable machine,
> accessing single bytes may be more expensive than accessing a
> complete word, and there are arguments both ways.

See, efficiency.

>
>> as for passing smaller integer types, these tend to be promoted
>> internally to the smallest convinient size (namely, int) anyways,

Right, but a type that need not be promoted does not need that extra
step.

>> and on common architectures this doesn't add any real cost (both x86
>> and ARM have instructions to load a byte from memory with sign or
>> zero extension).

>
> Depending on the context: on many machines, it may be just as
> fast to simply pass an int, with garbage in all but the low/high
> order byte (depending on endianness).

But compilers probably don't do that.

> The garbage doesn't
> matter, of course, because the callee won't ever look at it.
>
>> granted, yes, this does in-fact still depend on the compiler
>> though.

>
> As does just about everything else.

What is common practice though is the real concern because just about
everything in C++ is platform-dependent.

JBarleycorn, Jul 20, 2011
18. ### Ian CollinsGuest

On 07/21/11 08:46 AM, JBarleycorn wrote:
> James Kanze wrote:
>> On Jul 16, 6:02 pm, BGB<> wrote:
>>> On 7/16/2011 3:33 AM, MikeP wrote:

>>
>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>> useless as struct members. If one foregoes bools in structs, why
>>>> not then specify that bools should be the size of int and thereby
>>>> likely to be fast to pass to and from functions? (Is it less
>>>> efficient to pass less-than-word-size integers because then they
>>>> have to be sign-extended or zero-extended, or any other reason?)

>>
>> First, is size of bool unspecified? Or just implementation
>> defined?

>
> Isn't that the same thing?

Not in terms of the standard. Implementation defined things have to be
defined by the implementation.

>> The size of all types is implementation defined (with
>> a minimum size).
>>
>> And I don't see the issue with regards to structs.

>
> C compatibility where layout, then, matters? Data transfer/storage.

Then C++ added bool, C didn't have it so there was no layout
compatibility to maintain.

>>> IIRC, many compilers default to making them the same size as char,
>>> or a single byte. this tends to be most convinient as, bigger, and
>>> they are just wasting space, and smaller, as messing with bits is
>>> awkward and costly (as well as compromising their direct

>>
>> A bool is required to be addressable; sizeof(bool) is also
>> required to return an integral value. So a bool can't be
>> smaller than a char. On a byte addressable machine, there's
>> also no reason to make them bigger,

>
> Efficiency?

Maybe, but efficiency isn't only dependent on size. If it were, we'd be
using 64 bit ints on 64 bit machines.

--
Ian Collins

Ian Collins, Jul 20, 2011
19. ### Noah RobertsGuest

On 7/20/2011 1:46 PM, JBarleycorn wrote:
> James Kanze wrote:
>> On Jul 16, 6:02 pm, BGB<> wrote:
>>> On 7/16/2011 3:33 AM, MikeP wrote:

>>
>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>> useless as struct members. If one foregoes bools in structs, why
>>>> not then specify that bools should be the size of int and thereby
>>>> likely to be fast to pass to and from functions? (Is it less
>>>> efficient to pass less-than-word-size integers because then they
>>>> have to be sign-extended or zero-extended, or any other reason?)

>>
>> First, is size of bool unspecified? Or just implementation
>> defined?

>
> Isn't that the same thing?

Implementation defined has to be documented, unspecified does not. Both
are behaviors defined by the implementation.

Noah Roberts, Jul 21, 2011
20. ### JBarleycornGuest

"Ian Collins" <> wrote in message
news:...
> On 07/21/11 08:46 AM, JBarleycorn wrote:
>> James Kanze wrote:
>>> On Jul 16, 6:02 pm, BGB<> wrote:
>>>> On 7/16/2011 3:33 AM, MikeP wrote:
>>>
>>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>>> useless as struct members. If one foregoes bools in structs, why
>>>>> not then specify that bools should be the size of int and thereby
>>>>> likely to be fast to pass to and from functions? (Is it less
>>>>> efficient to pass less-than-word-size integers because then they
>>>>> have to be sign-extended or zero-extended, or any other reason?)
>>>
>>> First, is size of bool unspecified? Or just implementation
>>> defined?

>>
>> Isn't that the same thing?

>
> Not in terms of the standard. Implementation defined things have to be
> defined by the implementation.

Why is "unspecified" necessary? Does anyone think that not specifying the
size of a bool is a good thing?

How can bools be used in structs if every implementation can define it
differently?

>
>>> The size of all types is implementation defined (with
>>> a minimum size).
>>>
>>> And I don't see the issue with regards to structs.

>>
>> C compatibility where layout, then, matters? Data transfer/storage.

>
> Then C++ added bool, C didn't have it so there was no layout
> compatibility to maintain.

Oh yeah! The 2 groups should have coordinated the introduction of bool.

>
>>>> IIRC, many compilers default to making them the same size as char,
>>>> or a single byte. this tends to be most convinient as, bigger, and
>>>> they are just wasting space, and smaller, as messing with bits is
>>>> awkward and costly (as well as compromising their direct
>>>
>>> A bool is required to be addressable; sizeof(bool) is also
>>> required to return an integral value. So a bool can't be
>>> smaller than a char. On a byte addressable machine, there's
>>> also no reason to make them bigger,

>>
>> Efficiency?

>
> Maybe, but efficiency isn't only dependent on size. If it were, we'd
> be using 64 bit ints on 64 bit machines.
>

I meant efficient in time, not space. Are not 64-bit ints indeed more
efficient (in time) than 32-bit ints, say on x86 vs. x64? Anyone have a
good simple test for this? Probably at least 3 things need to be eval'd:
argument passing performance, return value performance, arithmetic
performance. I can compare the 8-bit bool vs. a 32-bit int on my machine,
but I don't have a 64-bit machine.

JBarleycorn, Jul 21, 2011