Re: Why use C++?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 12.08.11 17:14, Jed wrote:

>>   Then, will understanding the type declarations
>>
>>    type Intensity is range 0 .. 255;
>>    for Intensity'Size use 8;
> 
> Oh, but I thought you desired to abstract-away the representation. What's 
> that "Size use 8", then, all about?


The general idea is that you start from the problem
without giving thought to representation.  Typically,
without loss of efficiency.  Compiler makers know a fair
bit about good choice of representation.  This means:
Describe precisely what matters to your program, on
any machine, without reference to any representation.
Then, and only then, and only if necessary, throw in your
knowledge of representation.

Considering the RGB array example, you'd have to know that
the imaginary display hardware works better (or at all) if
Intensity values are 8 bit, and components aligned on 8 bit
boundaries, say.  Or that this must be so because a driver
program expects data shaped this way. Typically, though,
data representation is something a compiler should know
better, but of course nothing should be in the way of
a hardware savvy programmer.  Directing compilers can be
beneficial.  Still, this kind of direction should not
steer the structure of a solution.

When have you last thought about the size of the components
of std::string, of of a vtable?  Why, then, is there a
pressing need to think about the sizes of int types?

A few programming issues typically arising from choice of
type.  They key word here is "typical", as in "real world":

1. Change of platform.

A programmer uses language defined type int (or Integer)
all over the place, assuming that objects of the type will
have 32 bit words.  Later, the program should be ported
to a 16 bits platform.  Ouch!  May need to review the entire
program.

The C solution is to at least become aware of the powers of
typedef + discipline + conventions.  Add assertions, compile
time assertions already mentioned, or templates like Hyman
Rosen's. Try isolating and checking the consequences of type
choice. In any case, this seems like a fair bit of mechanism,
and procedures in a programming organization that is outside
the language.

An Ada solution is to avoid Integer where possible
and declare the types you need in the most natural way,
which is by specifying the range of values you need.
Full stop.  (Well, mostly, but is is a lot easier and
to achieve the same goal.)

Any language with a natural way of defining types from abstract
problem domain knowledge has the same advantage in that the
definition doesn't refer to types like int or Integer, but
to the non-changing abstract solution.

2. Changing representation.

When I want to change a type's objects' representation, I must
pick a different type in C.  In Ada (or ...), I'll leave the type
declaration as is, and ask the compiler to represent it differently.
The rest of the program's logic is not affected, as the type's
value set stays the same.

The C way slightly reverses thinking about the program,
then. You must start from the set of fundamental types
and from the set of values they happen to have in some
implementation. Not from the values you need.  You cannot
declare a type that includes precisely the values required
by your solution.  You can apply your knowledge of
the implementation when choosing a type that best
represents your "real" type.  Using C++, I imagine you
can produce clever template computations to this effect.
I'm only guessing, though.  All of this, however, is not as
simple as simply stating that your type's value set should
be such-and-such.

As a simpler example, consider percentages as whole numbers
between 0 and 100.

An exception is when the program is about hardware.
Side note: it is a requirement that an Ada implementation
make all "hardware types" that it supports available to the
programmer.