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: 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: Sun, 14 Aug 2011 00:22:28 -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> <4e4645c0$0$7629$9b4e6d93@newsspool1.arcor-online.net> Injection-Date: Sun, 14 Aug 2011 05:56:19 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="KjJVZ+2pm40y3WME79WlsQ"; logging-data="6698"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19vtrdrVT+7POHKOXuvEpql" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Cancel-Lock: sha1:QR/5mvoc3BZYsqRFpr56zH78Fio= X-Priority: 3 X-MSMail-Priority: Normal Xref: g2news2.google.com comp.lang.c++:92719 comp.lang.ada:21590 Date: 2011-08-14T00:22:28-05:00 List-Id: Georg Bauhaus wrote: > On 12.08.11 21:51, Jed wrote: > >>> 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. > > > Specifying representation when needed, and separate from > the type declaration, works perfectly well for I/O. > For I/O in particular! Maybe true, but maybe I'd agree, and maybe I'd maybe I'd "bail out" at the last step before boarding the airplane, which of course I could maybe never ever do, for being so afraid of being in the sky under someone(s) else's control... I mean, like Rain Man. > > Short summary: > > Declaring a type for computation does *not* require specification > of representation. That goes without saying. But maybe I LIKE it that way. > However, should it become necessary It's not a question of necessity. > to > specify a representation of objects of a type, the programmer > should be able to do so, but *not* by forcing the representation > into every existing type. Maybe, but maybe that is too "pie in the sky" academia/wishful-thinking, etc. Who are the beneficiaries of such and it is a benefit at all? > > > (Incidentally, bit-oriented, abstracting types (bit fields > in C, std::bitset in C++, bit arrays in D, or packed arrays of > Booleans in a host of Pascalish languages) don't make a > language 4GL.) I know what a 4GL is, do you? ;) > > Examples of how omitting (implied) representation from type > declaration works well with I/O. > > 1. (I/O As-is) Suppose I/O means writing to a particular address. > There is an output port to write to. It has CHAR_BIT bits, > and CHAR_BIT == 8. You want to write an object of type long > which happens to consists of four octets. One approach is to > write a function that shifts bits into a char object and then > pushes this object out the port. > > Using the fundamental type system of C++, you need some size > computations, at compile time, or by the programmer, so that > the program will perform the right number of shifts, for a > given implementation. With C++ and long, long[], etc, there > are idioms. They typically use the sizeof operator, and division. > > The very same technique is available for objects declared of a > type 1e0 .. 1e5 that does not mention any other type's name! > The programmer may leave it to the compiler to choose a > representation for objects of type 1e0 .. 1e5 that is > best on the target hardware for computation. For I/O, the > programmer again uses the type system and inquires of the type > how many octets there are in the type. But! He does not have > to name a type for the "computational objects", such as > declaring them to be "long", he just lists the values that > should be stored in objects of the type, and exactly these, no > more, no less. Pfft. There is no "int", "long", "short"... but there is int32, uint8, etc. Don't bother me with past mistakes. Given that, then move on. All else is banter/irrelevant (to progress). > > In pseudo code, > > type T is exactly 1e0 .. 1e5. > T obj. // representation left to the compiler > > // compute, compute, compute, ... then, > > for k in [0, octet_size(T)) do > x <- shift_octet_from (obj@k), > write_octet(x, port_address) > done. Ech, I have to skip past example code mostly. Until the higher level is worked out. "Design in code" is a fantasy (for the most part, it is just wailing on the guitar, which is, of course, masturbation). > > 2. (Conversion) Suppose I/O means writing a number of structured > objects to a stream. Suppose? Suppose this: there is no "stream". :P