Re: Why use C++?

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

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

>>> Size guarantee?
>>> Other than that, what
>>> is ambiguous (platform-specific) about C++ int?
>>
>> That is one of the meanings of ill-defined.
> 
> Don't use it.

Which was the point.

>> BTW, if you aim at this application domain, note endianness and encoding
>> stuff. You have very little chance that int is the type the protocol or
>> hardware uses.
> 
> Picking on int?

int, long, unsinged represent an example of wrong language design. The
point was that the semantics of an [integer] must be derived from the
application domain.

>> In each such case I will have to use a type different from the machine
>> type. This is just another argument why types need to be precisely
>> specified. I addressed this issue above.
> 
> But they are precisely specified on any given platform.

1. They are not. In order to see the specification of int, you have to read
the compiler documentation. My point was that the program code does not
specify the properties of int. The answer that it is defined somewhere
somehow is not an argument at all, anything works in this or that way.

2. I don't care about the platform, I care about what the program is
supposed to do. The type's properties shall be defined by the application
domain.

>> Just another layer of
>> abstraction above states of the p-n junctions of some transistors. Do
>> you care?
> 
> At some level, I care, yes. At that level, no. I'm not against your 
> proposal, I just don't know the scope of it. I have a feeling that going 
> to the level you are calling for is what would say is "an exercise" 
> instead of practical engineering. Just a feeling though, mind you. Tell 
> me this, how close is Ada (and which one) to your ideal? All I know about 
> Ada is what I've read about it. Maybe I should write some programs in it.

Ada is close, but not close enough. It is light years ahead of C++
concerning numeric types, so the problems with Ada might be difficult to
understand for a C programmer. Ada puts too much magic into numeric types.
I would prefer less. Ada lacks numeric interfaces abstracted away. Ada
lacks mapping of classes of numeric types onto proper types. [There are
classes, but no objects] Exceptions are not contracted. Too many things
required static. Other things are dynamic while should have been static,
etc.

>>>>>> (The way compiler would implement that type is uninteresting,
>>>>>
>>>>> Ha! To me that is KEY.
>>>>
>>>> This is not a language design question. It is a matter of compiler
>>>> design targeting given machine.
>>>
>>> Oh? I've been having a language design discussion (primarily).
>>
>> Then that cannot by any means be a key issue.
> 
> That's opinion, not fact.

It is a conclusion from the fact that we were discussing language design
issues rather than code generation problems.

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

But design by contract is a mere engineering principle, it applies
absolutely everywhere in engineering. If you disagree, please, show
examples.

[I don't mean here Meyer's notion of DbC, which is largely wrong, IMO]

>>> Well then, if wrapping is OK, what else is needed and why?
>>
>> Wrapping is an implementation, the question is WHAT does this
>> implementation actually implement?
> 
> I was just asking why you find that inadequate such that something 
> (largely more complex?) is needed.

Hmm, then I didn't understand your question.

> 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. Implementation of the RTL is a
different issue.

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

>> Contract specifications. "int" is not a contract.
> 
> Does Ada meet your desired requirements?

Ada is the closest existing approximation.

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