Re: Why use C++?

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

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4e44e50a$0$7619$9b4e6d93@newsspool1.arcor-online.net...
> On 12.08.11 07:03, Jed wrote:
>> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  wrote in message
>
>>> Ada does not have predefined modular types in the package Standard,
>>> because
>>> any modular type can be constructed using "type T is mod N" 
>>> construct.
>>
>> OK, I plainly see what you meant now even without your example. It's
>> amazing what a good night's sleep will do. Last night, I was keying-in 
>> on
>> the word "algebra" too much and it blinded me to the overall meaning.
>>
>> I'm not sure I'd want that level of flexibility in a language. I think 
>> it
>> may be too much effort for too little benefit. It seems it may be 
>> doing
>> something in software that could be supported in hardware but isn't 
>> (?).
>> Maybe too much of a "purist" approach. I'd need more info about it and 
>> be
>> convinced it is worth it before I'd put that on my shortlist of
>> compelling features for a language to have.
>
> Perhaps it is info if beginners in embedded systems programming
> consistently produce much better results (statistics collected
> and testedover some 6 years) when they have an expressive  and
> likely more intuitive type system for fundamental types.

While that is definitely a good characteristic, I can't evaluate it 
without knowing what effort it takes to get it. Certainly something like 
ranged types is easily doable. I'm not sure the scope of what is being 
called for by those calling for it (e.g., Dmitry), that's the problem. I 
ranges is one thing, what are the others?

> My guess
> is that the absence of representation riddles is a boon.

I would say that abstraction is nice sometimes, but if you don't have any 
guarantee of the representation, then that is necessarily a higher-level 
language than C and C++ are (i.e., higher than "close to the metal).

> Put yourself
> in the position of a beginner who is woken up at 5p.m. They would not
> recall the rules regarding enum vs int, or the collection of 
> traditional
> idioms for declaring arrays in C, autotruncation of numeric values
> to fit in the space of LHS; and likely neither the more modern
> classes addressing hardware things.

Some of those things are decicely deficient, yes, but that is not to say 
that abstracting-away the representation is always good. Indeed, do that 
and you have a 4GL rather than a 3GL.

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

>    type RGB is (Red, Green, Blue);
>    type Pixel is array (RGB) of Intensity;
>
> require much besides what is written?   Compare
>
>    #define RGB_LIMIT 3
>
>    typedef unsigned char Intensity;
>    enum RGB {Red, Green, Blue};
>    typedef Intensity Pixel[RGB_LIMIT];
>
> and
>
>   switch (1) {
>   case 0: break;
>   case CHAR_BIT == 8: break;
>   }
>
> somewhere.  If I am a beginner, what is the number of technicalities
> I must know it order to understand the second way of declaring things?
> (I'll leave out that the declare-like-used rule in typedef is
> confusing many. Maybe that's because the typdef-ed name isn't in some
> fixed position in the typedef.)