Re: Size of bool unspecified: why?
On Jul 22, 11:17 pm, "JBarleycorn" <jbn...@newsnet.org> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:2ba060fd-d11e-4cda-b0c8-1038a58b6cf6@a31g2000vbt.googlegroups.com...
[...]
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++.
Now we're getting somewhere! You saying that you code against a
*"philosophical"* paradigm.
I'm saying that I use data abstraction, as a tool to manage
complexity.
The word "religion" will surface soon, I'm
sure. Then you can say that my designs are unholy and yours are holy and
then the congregation you belong to will ... something.
There's no religion about it: the higher the level of
abstraction, the more efficient the programmer. Given a good
compiler (something rare), the more efficient the generated
code, too. Against higher levels of abstraction: it's often
more work (defining a class, where just using int will do), and
some particular interfaces (including most serialization) are
defined in terms of a low level of abstraction.
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.)
Like I *said*: there is no *similar* type.
Except all signed integral types.
[...]
Exactly like every other integral type.
I'm not going to repeat myself.
Because there's nothing to repeat? To date, you've yet to give
any concrete reason why there's a problem with bool. Just vague
assertations which aren't supported by actual facts.
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.
1. The size of C++ bool can't be relied on.
So what? If you're worried about the size of bool, you're
worried about the wrong things.
2. C++ bool has brain-damaged behavior (promotion to int).
I wouldn't go so far as "brain-damaged" (unless you want to
argue that C++ is brain-damaged everywhere, because it is based
on C). It's regrettable. It's also necessary, for reasons of
backward compatibility. Like the original authors of the
proposal, I would have preferred that the implicit conversions
be deprecated, but there was no consensus in the committee for
this, so it wasn't.
(As I've mentionned earlier, I
expect that bool is a single byte on most, if not all, byte
addressed platforms.)
Now it is, but historically, I have an incling, that on all those
platforms, bool was synonymous with int. In that case, you have just
different versions (old and new) of the compiler and encounter a size
change of type (or synonym) bool.
Historically, there wasn't a type bool, and a lot of programmers
used:
typedef int bool;
(I wouldn't be surprised if <windows.h> still has a typedef for
BOOL. Or maybe a macro.) I don't think that any implementation
on a byte addressable machine has ever made it more than a byte.
(But since I've never worried about it, I could be wrong.)
--
James Kanze