[ ... ]
I am sure the standards committee didn't make up these rules just for
fun, but were well aware that specifying seemingly tiny details would
make it impossible to implement the language on a wide range of
hardware.
There's really quite a bit more to the situation than
that.
By not specifying some variations ('being vague'), you don't
limit yourself to:
8 bit bytes
2^n bytes per datatype
two's complement integers
no pad bits
'a' == 0x20
[ ... ]
There's a lot more at stake here than just a minor
tradeoff between ease of writing portable code and ease
of writing a compiler that produces efficient code.
One basic intent of C++ is that it should support
essentially any kind of programming that C did/does. One
of the things for which C (and therefore C++) is intended
to be used is system programming, such as implementing
operating systems.
Just for one minor example, consider the result of
mandating the sizes of types. If you were going to do
that, you'd almost certainly mandate them as powers of
two. If you do that, however, you make it essentially
impossible to any longer use C++ to write something like
the OS (or any other "bare metal" code) for almost any
machine with an unusual word size.
Contrary to some people's beliefs, such unusual word
sizes are NOT merely strange leftovers from a bygone era,
nor is there any reasonable likelihood that such machines
are going to go away anytime soon. Consider, for example,
the specs on the TI TMS320C3x DSPs:
32-bit floating point
24-bit fixed point
40-bit registers
Likewise, the Motorola DSP 563xx series:
24-bit addresses
24-bit fixed point data
56-bit accumulators
It's not particularly difficult to find more examples
either.
To summarize: the fundamental question here is primarily
whether you want an applications programming language or
a systems programming language. There is certainly room
in the world for applications programming languages --
but that's never been the intent of C++.