Size of bool unspecified: why?

[MikeP]

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]

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.

 

[Ian Collins]

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]

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.

I'll return to your post after RW replies.

 

[MikeP]

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

I am not a warrior.

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

 

[MikeP]

Robert Wessel wrote:

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

 

[MikeP]

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

I am not a warrior.

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

Please don't top-post.

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

 

[Juha Nieminen]

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?

 

[James]

Robert Wessel wrote:

[...]

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

Are you really that moronic?

Wow! :^)

 

[MikeP]

Robert Wessel wrote:
[...]

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

Are you really that moronic?

Wow! :^)

I have my moments\

 

[MikeP]

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

So the answer would then be adolescent stupidity\

 

[James]

Robert Wessel wrote:
[...]

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

Are you really that moronic?

Wow! :^)

I have my moments\

;^)

 

[Ian Collins]

I have my moments\

Some moments are best enjoyed in private.

 

[MikeP]

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).

 

[James Kanze]

On 7/16/2011 3:33 AM, MikeP wrote:

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]

So the answer would then be adolescent stupidity\

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

 

[JBarleycorn]

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.

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.

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

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.


As does just about everything else.

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

 

[Ian Collins]

Isn't that the same thing?

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

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.

Efficiency?

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

 

[Noah Roberts]

Isn't that the same thing?

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

 

[JBarleycorn]

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?

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.

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.