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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!feeder.news-service.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "Jed" Newsgroups: comp.lang.c++,comp.lang.ada Subject: Re: Why use C++? Date: Fri, 12 Aug 2011 14:51:20 -0500 Organization: A noiseless patient Spider Message-ID: 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> <4e44e50a$0$7619$9b4e6d93@newsspool1.arcor-online.net> <4e4560e7$0$6546$9b4e6d93@newsspool4.arcor-online.net> Injection-Date: Fri, 12 Aug 2011 19:51:06 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="MIpMIVYD9PDhsUAPC84lbA"; logging-data="3935"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/SJ6CSytxbv25GY3ARTp7D" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-RFC2646: Format=Flowed; Original X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Cancel-Lock: sha1:lNJlDX0Q9NZ4KyOne6tnJEeHNGw= X-Priority: 3 X-MSMail-Priority: Normal Xref: g2news2.google.com comp.lang.c++:92650 comp.lang.ada:21552 Date: 2011-08-12T14:51:20-05:00 List-Id: "Georg Bauhaus" 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 = 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"?