Re: Why use C++?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 13 Aug 2011 23:29:12 -0500, Jed wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 13 Aug 2011 02:53:32 -0500, Jed wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1gu6ni1yb54k3$.4nbvfqqndl8m$.dlg@40tude.net...
>>>> On Fri, 12 Aug 2011 14:06:55 -0500, Jed wrote:
>>>>
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>>> news:fwnlcp4mgj03$.1tjeqjtos00o8$.dlg@40tude.net...
>>>>
>>>>>> I want the type semantics specified. C/C++ int is neither lower
>>>>>> level nor closer to the machine it is just ill-defined. The
>>>>>> concern is this, not its relation to the machine, of which I (as
>>>>>> a programmer) just do not
>>>>>> care.
>>>>>
>>>>> What more definition do you want?
>>>>
>>>> More than what? I see nothing.
>>>
>>> The semantics of C++ types are specified.
>>
>> By the word "int"?
> 
> By "specified", I mean "you know what to expect" (being, you have not a 
> guarantee).

No, "what to expect" follows from the specification. E.g. "the can opener
operates in the temperature range -10..+40 �C". This is a specification.
"The can opener may operate at some temperature" is not.

>> int, long, unsinged represent an example of wrong language design.
> 
> I agree (did you mean in C++, or in general?).

In general. It is

1. untyped approach. Not because of implicit conversions, which are bad of
course. The main reason is that the programmer should be encouraged to
choose different integer types for semantically different things, even if
numerically these things could be implemented by the same type.

2. Lack of contracts, machine/language- rather than application domain
driven choice of types.

>>  The
>> point was that the semantics of an [integer] must be derived from the
>> application domain.
> 
> Maybe it's good enough in a lot of instances. Say, a memory address. 
> 32-bit unsigned address works nicely (on a 32-bit machine).

Address is not an integer type. Consider segmented architecture as an
example.

>> My point was that the program
>> code does not specify the properties of int.
> 
> And I'm saying, maybe ("maybe" is a key word here) that is just a purist 
> approach and not better than practical compromise.

A compromise between what and what?

>> 2. I don't care about the platform, I care about what the program is
>> supposed to do.
> 
> Another way to skin the cat: write to a virtual machine. Java. .Net.

No, it is an attempt to constrain to one platform. VM, when used, is *the*
hardware. As history shows, all such attempts were in vain.

>>>>>> Why should you? Again, considering design by contract, and
>>>>>> attempt to reveal the implementation behind the contract is a
>>>>>> design error. You shall not rely on anything except the contract,
>>>>>> that is a fundamental principle.
>>>>>
>>>>> While that paradigm does have a place, that place is not
>>>>> "everywhere".
>>>>
>>>> Where?
>>>
>>> The formality of "design by contract" as used in developing
>>> functions/methods.
>>
>> That is a procedural view on software developing [a very outdated one,
>> IMO].
> 
> No it is not. Classes have methods. (I'm surprised you even said that).

Yes, they do. Yet an ADT (class is a type) is seen as something more than
just a collection of subprograms. It is not just methods (and other
operations) are subjects of contracts.

> I furthered 
> saying that I have a feeling you are seeking some "purist" ideal or 
> something for comp sci labs in academia.

Not at all. I am looking for a language for practical projects we are doing
(automation, embedded, networking, RT systems). Using a bad language is an
economic disadvantage.

>>> Oh, you were thinking something else when I wrote: "Can that be
>>> achieved? At what degree of complexity?". I asked if creating your
>>> ideal language (this "definitively specified higher level" language)
>>> is feasible and if so, what does that do to the complexity of the
>>> implemenation (compiler)?
>>
>> I think it should make the compiler simpler.
> 
> Do explain please. I can appreciate that in the abstract things look 
> rosey, but the devil is always in the details. One can design the perfect 
> bridge, but the problem is that landscapes are never perfect.

It is simpler to perform semantic analysis if you have a unified types
system. Each special case multiplies complexity.

>>> Is a comparison of Ada and C++ pretty much that answer?
>>
>> As a matter of fact, since I partially did both, to compile Ada is way
>> simpler than to compile C++.
> 
> That's not saying much of anything. Compare it to C.

K&R C or ANSI C? Up to the semantic analysis Ada 95 is much simpler than C.
After that C should be simpler.

> I think it has this "module as class-like thing" that seems so 
> archaic,

Hmm, actually it is C++, which conflates types (classes) with modules. This
error is shared by many OOPLs. In Ada a module (package) can provide any
number of types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de