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: 109fba,cd8ed9115942852f X-Google-NewGroupId: yes X-Google-Thread: 103376,b92b95c9b5585075 X-Google-NewGroupId: yes X-Google-Attributes: gid4f1905883f,gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!feeder.news-service.com!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!news.weisnix.org!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 12 Aug 2011 19:20:39 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 Newsgroups: comp.lang.c++,comp.lang.ada Subject: Re: Why use C++? 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-ID: <4e4560e7$0$6546$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 12 Aug 2011 19:20:39 CEST NNTP-Posting-Host: c188c8b6.newsspool4.arcor-online.net X-Trace: DXC=JhI[Oa^hROdEB;5>eE0T7m4IUKjLh>_cHTX3jm@>]XV\5hAYe X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.c++:82879 comp.lang.ada:20579 Date: 2011-08-12T19:20:39+02:00 List-Id: 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. 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. 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? 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. 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.) 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. 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. 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. 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.