Re: Size of bool unspecified: why?
On Jul 22, 12:52 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
James Kanze wrote:
[...]
Their use is fairly limited, and I can't
think of a case where I'd use them in a struct. (They are
convenient for certain operations, however, when their
restricted portability isn't an issue.)
You view of the concept seems to be exactly the opposite of mine. Your
view seems more appropriate, to me, for a 4GL rather than for C/C++.
My view is based on Kernighan and Richie. It was current thirty
years ago, and dominates things like Unix kernel code (which is
hardly written in the spirit of a 4GL).
bool is unusable in structs in many instances then.
You keep saying this, but it flies in the face of actual facts.
It depends on how you program. When I say that, I mean for the way I
program and use the language.
I'd still be interested in seeing an actual example where the
size of bool makes a difference. Suppose it was required to be
1: XDR requires it to be four bytes, so if you're serializing in
XDR format, you write:
void
writeBool( std::ostream& dest, bool value )
{
writeInt( dest, value ? 1 : 0 );
}
or something along those lines. Code which, of course, works
equally well if the size of bool is something other than 1.
People use bool in structs all the time, with no problems.
If I had to be continually faced with having to think about what the
effect of integral type size changes would be in C++, I would not use the
language. Though maybe I wouldn't program at all then!
Who thinks of it? Ever. About the only thing one might
consider is whether the type is large enough: I've seen a lot of
code which uses long, rather than int, because INT_MAX is only
guaranteed to be 32767. This even in code that will clearly
never run on a 16 bit machine. *IF* I felt I had to take this
into consideration, I'd use things like int_least32_t or
int_fast32_t. (But if the code clearly will never be used on a
16 bit machine, I'll just go with int.)
Serialization is not a panacea, it's tedium.
You've mentionned serialization several times, but you've yet to
explain how the fact that the size of bool being implementation
defined affects it in any way. The internal representation
doesn't generally affect serialization. And it varies, not just
for bool, but for int.
int and bool are in the same boat in that respect. The *only* time I use
int, or its unsigned counterpart, is when I consciously *want* a type to
expand across 32-bit and 64-bit platforms, and yes, I test in a header if
my assumptions are valid on a given platform. I view fixed-width integral
types, even if I have to synthesize them as I did before there was
stdint.h, as the "normal" ones and the "expanding" types as the special
ones. Try it sometime and you'll probably never go back to the other way
of thinking.
Why? It sounds like a major step backwards to me, and it
certainly isn't how the language was designed to be used.
--
James Kanze