From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,b92b95c9b5585075 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news4.google.com!feeder2.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.85.MISMATCH!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.c++,comp.lang.ada Subject: Re: Why use C++? Date: Fri, 12 Aug 2011 22:05:32 +0200 Organization: cbb software GmbH Message-ID: <1gu6ni1yb54k3$.4nbvfqqndl8m$.dlg@40tude.net> References: <1e292299-2cbe-4443-86f3-b19b8af50fff@c29g2000yqd.googlegroups.com> <1fd0cc9b-859d-428e-b68a-11e34de84225@gz10g2000vbb.googlegroups.com> <9ag33sFmuaU1@mid.individual.net> <1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net> <150vz10ihvb5a.1lysmewa1muz4$.dlg@40tude.net> <1q4c610mmuxn7$.1k6s78wa0r8fj.dlg@40tude.net> <1vn800hbyx8k4$.1lsveclj56197$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: eDNFN6/+jOFqgaV1SjmKUA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news2.google.com comp.lang.c++:92652 comp.lang.ada:21554 Date: 2011-08-12T22:05:32+02:00 List-Id: On Fri, 12 Aug 2011 14:06:55 -0500, Jed wrote: > "Dmitry A. Kazakov" 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. > Other than that, what > is ambiguous (platform-specific) about C++ int? That is one of the meanings of ill-defined. >>>>>> That depends. In Ada integer types are constructed from ranges. >>>>> >>>>> Oh, I thought ranges in Ada were "subtype ranges", hence being based >>>>> upon >>>>> the built-ins. >>>> >>>> Both: >>>> >>>> type Tiny is range -100..100; -- A new type >>>> subtype Nano is Tiny range 0..2; -- A subtype >>> >>> What underlies those "new" types though? >> >> That is up to the compiler. > > Do you care about the size of the type ever? You mean the size of the representation taking into account its memory alignment? I don't care except for the cases I have to communicate the hardware or to implement a communication protocol. Though I have to do this quite often, so I cannot represent a typical case, not so many people are doing embedded/protocol stuff these days. Anyway, that is well under 1% for me. 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. In fact, you need here even more language support, because the type semantics is to be defined far more rigorously. You need to take the description of the protocol and rewrite it in the language terms. Even Ada's representation clauses cannot this, e.g. to describe the integers used in an analogue input terminal (as an integral type). >>> Aren't they just "syntactic" sugar over some well-defined primitives? >> >> What are "well-defined primitives"? > > The built-in things that are closest to the machine, with consistent > representation across machines that can be relied on, that other things > are built on top of. (That's a stab at it, anywho). How these contradictory requirements could be fulfilled by something well-defined? In fact the vagueness of such "primitives" is a consequence of that contradiction. There is no such primitives, in principle. >>> Wouldn't they have to be? I.e., >>> at some point, the hardware has to be interfaced. >> >> Yes. Consider a that the target is a pile of empty bier cans maintained by >> a robot. I presume that somehow the position of the cans or maybe their >> colors in that pile must reflect values of the type. Why should I (as a >> programmer) worry about that? > > Because you know it isn't beer cans (call it, say, "a simplifying > assumption") and you may want to (probably will want to) send some of > those integers to another machine across the internet or to disk. 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. >>>> Mathematically there is no need to have a supertype containing the >>>> ranged one. >>> >>> I'm only concerned about pragmatics (implementation). >> >> It is simple to implement such a type based on an integer machine type when >> values of the language type correspond to the values of the machine type >> (injection). It is less simple but quite doable to implement this type on a >> array of machine values. The algorithms are well known and well studied. I >> see no problem with that. > > Just another layer of abstraction. So it's as simple as that (another > layer of abstraction), yes? Yes, what in your opinion a machine word is? Just another layer of abstraction above states of the p-n junctions of some transistors. Do you care? >>>> (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. >> 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 comments being made in this thread are really suggesting 4GL. While > that is fine, there is a place for 3GLs and hybrids. One size fits all, > really doesn't. Maybe, but in software engineering it certainly does. > 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? >> Inadequate would be to expose such integer types in the contracts. > > What contracts? >> Implementations based on existing types are possible, but you would need >> much language support (e.g. reflection) in order to ensure that the >> implementation fulfills the contract. As an example, consider an >> implementation of >> >> type I is range -200_000_000..100_000; -- This is the contract, which >> -- includes the range and the behavior of +,-,*/,**,mod,rem, >> overflow >> -- checks etc >> >> on top of C's int. > > Oh, THAT "contract". (I reserve that term for function calls, just to > avoid overloading it, but I actually prefer "specification" as I > associate "contract" with Eiffel). > > I'm don't know what you are suggesting the ideal implementation would be > of the ranged type above. There is no ideal implementations, there are ones fulfilling functional and non-functional requirements. >>>>>> The point is that it is the application domain >>>>>> requirements to drive the design, and the choice of types in >>>>>> particular. >>>>> >>>>> Can that be achieved? At what degree of complexity? >>>> >>>> We probably are close to the edge. >>> >>> Meaning "highly complex"? >> >> Enough complex to make unsustainable the ways programs are designed >> now. > > Explain please. If the bugs rate will not be reduced, there will not be enough human resources to keep software development economically feasible. And this is not considering future losses of human lives in car accidents caused by software faults etc. >>>>> Can it/should it be hardware-supported? >>>> >>>> No. Hardware becomes less and less relevant as the software >>>> complexity increases. >>> >>> OK, so another layer of abstraction is what you want. The syntax of, say, >>> Ada's ranged types, for example. So your call is just for more syntactic >>> sugar then, yes? >> >> Rather more support to contract driven design and static analysis. > > That doesn't appear to be a lot of complexity to introduce into a > compiler. It seems like common sense. So, what am I missing here? Contract specifications. "int" is not a contract. > The new enums in C++11 are a step in the right direction, yes? Maybe in > the next iteration we'll get ranges. Let's see. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de