Re: Size of bool unspecified: why?
On Jul 22, 12:29 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
Ian Collins wrote:
On 07/21/11 07:56 PM, JBarleycorn wrote:
"Ian Collins"<ian-n...@hotmail.com> wrote :
On 07/21/11 04:28 PM, JBarleycorn wrote:
"Ian Collins"<ian-n...@hotmail.com> wrote:
On 07/21/11 12:32 PM, JBarleycorn wrote:
How can bools be used in structs if every
implementation can define it differently?
The same way ints can be used in structs when every
implementation can define them differently.
You can used fixed-width integers but there is no
complementary bool type. bool is unusable in structs in
many instances then. Serialization is not a panacea,
it's tedium.
The only places where sizeof(bool) matters it will be defined.
The need for fixed-width integers has been proven and
therefore they are in the standard, but then they forget
the past and create a new type and don't consider that
width matters for that type. Either that or they considered
it not useful in the situations where the fixed-width
integers are a boon. They should have specified a width, as
the alternative of having multiple booleans of different
widths isn't practical I believe.
That argument doesn't make sense, given we have fixed with
types, why should the with of any natural type be fixed?
The analogy with int still applies. If I want a 32 bit
signed type, I'll use int32_t. Whether that is an int or a
long under the hood is irrelevant.
A header of an application program can check if fixed-width
integer types are what the program expects and if not, then
adjustments can be made, but with bool, whaddaya going to
do if the size of bool doesn't meet the app's expectations?
Who often have you needed to know the size of bool? What do
you do if sizeof(int) isn't what the program expects?
Why would anyone expect sizeof(int) to be anything specific?
int is not an issue. The fixed-width sizes are an issue, but
you can test for it and do whatever is necessary to maintain
consistency.
You use a different type.
A different numeric type, which there are a number to choose
from. Who writes a program that doesn't have a header that
tests for assumptions based upon the platform?
Who does? In over thirty years of experience in C and C++, I've
yet to see any application which uses such a header. I'm
tempted to say that someone who uses such a header doesn't
understand the basic philosophy behind C and C++.
How is bool different?
If bool doesn't meet your expectations, you don't have the option to
change to a similar type of different width, because there is no similar
type of different width.
Sure there is: signed char, short, int and long are all similar
types, with potentially different widths. (Don't ask me why
bool is a signed integral type, rather than an unsigned one.)
You have to change compilers or something. *Or*, avoid bool
from the get go noting from the start that you can't rely on
the width of bool.
Exactly like every other integral type.
Use an integer of the right size? What's the point of
having a bool at all then if it is likely that some
compiler or version of it doesn't support the needed type?
Again, how often is the size of a natural type important?
*Very* often.
For example? You keep saying it's important, but I've only
encountered the case in a few rare instances. (For starters, it
can't be important in portable code.)
How often in real code do you use a fixed width type?
*Very* often.
Then there's something wrong with your programming style.
*Very* much more often than using non-fixed-width integral
types.
Then there's something very wrong with your programming style.
I'm sure I use them more than most because a lot of my work
is on embedded platforms or drivers.
Well there you go then.
Drivers are a bit special, but even in drivers, it's not rare to
use the standard types. And of course, unless things have
changed enormously since I was writing drivers, the fixed width
types don't occur in structs.
[...]
No, not likely for then bool would be eliminated from a lot of places
where it could be used to good effect. I think multiple-width boolean
types can be made to work, but the complexity is not worth it, so 1-byte
bools, even though there may be a performance penalty on most platforms,
are probably the best choice. I have pretty much decided that where a
"fast bool" is needed it's a profile/optimizaation thing and trying to
find an optimum boolean type size as the best compromise across a set of
platforms falls into the category of premature optimization. Therefore,
the overriding concern is suitability for use as a struct field. So, my
boolean class uses a 1-byte type as the underlying type.
That sounds like the most rational decision. Or rather, you use
the bool the implementation gives you, until you need something
faster for your application. (As I've mentionned earlier, I
expect that bool is a single byte on most, if not all, byte
addressed platforms.)
--
James Kanze