Re: Why use C++?

["Jed" <jehdiah@orbitway.net>]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4e4560e7$0$6546$9b4e6d93@newsspool4.arcor-online.net...
> 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.

That doesn't work when you do IO. Unless, of course, you are suggesting 
that IO should be abstracted away. Which is fine, if you want that, but 
it necessarily moves one into 4GL-land.

>
> 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.

So the benefit, then, just not having to learn something? An electric 
food slicer so that the knives can be put in a locked box?

>
> 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?

You know that that was a very bad comparison. Completely invalid.

>
> 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.

Such is a language that must maintain backward compatibility. Easy 
solution: don't use int (and learn the language you are programming in). 
The above is a bug. Sure, it was cause by the failings of the language, 
but one is supposed to know those "gotchas". C++ is not for "quick and 
dirty" programming tasks unless one is highly skilled in the usage of the 
language, knowing the ins and outs. Yes, it's easy to imagine something 
better, but that isn't C++, and the comments being made in this thread (I 
keep saying this) seem to want to move from 3GL territory to 4GL.

>
> 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.)

I like the semantic also (not the syntax though). I still don't have a 
feel for the scope of the desired (your) semantics and the compiler 
implementation effort requited though. So far, I'm clear on "ranged 
integers + size attribute".

>
> 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.

Still, 80% solutions are good sometimes too. That "last 10%" can 
exponential increase <something>. (something = complexity or $ or 
time...). So, scope first, then gap analysis (and other analyses) to 
determine if it is worthwhile. Ranged integers? Sure, why not. Something 
more than that, well, the whole scope needs to be presented.

>
> 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.

So, a control panel on top of the low-level things. (4GL vs. 3GL).

>
> 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.

I think that may be an incremental improvement from the application 
development standpoint. If it was exclusively that, it could become 
tedious. From the compiler implementation standpoint, maybe not worth 
doing too many things beyond, say, ranged integers. Again, what is the 
scope of your proposal? Just saying "a semantically rich programming 
language..." is quite nebulous. I'd like to see a list or something. 1. 
Ranged integers. 2. Scoped strong enums (got that already). 3. ???

>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.

Ah ha! ;) In conjunction with all you've said so far, I'll bet you will 
say that IO should companionally be abstracted-away too. That's fine, but 
now, is that a programming language, or an environment? How far on that 
track do you go before you start calling the language "Windows"?