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: 103376,442eb9212004f30 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!newsfeed.freenet.de!news.tu-darmstadt.de!newsfeed.velia.net!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 11 Jul 2008 11:49:06 +0200 From: Georg Bauhaus Reply-To: rm.tsoh-bauhaus@maps.futureapps.de User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Problem using Ada.Text_IO.Modular_IO References: <4eab7055-df3d-4d56-87da-8248829da1da@26g2000hsk.googlegroups.com> <32e35e5a-3cae-4fdc-be4a-3ae1e146e9f3@l64g2000hse.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <48772c92$0$6601$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 11 Jul 2008 11:49:07 CEST NNTP-Posting-Host: 9436be4c.newsspool2.arcor-online.net X-Trace: DXC=MaXWV3CO\VkOKO]LCQ@0g`A9EHlD;3Ycb4Fo<]lROoRa8kFejVhAJ<FA=KeiE8bE15YR\` X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:1108 Date: 2008-07-11T11:49:07+02:00 List-Id: anon wrote: > Why re-invent the Wheel!!! If we spend all day re-stating that which > has been done then nothing new get done that day! As Adam is pointing out below---in two paragraphs which I think are really recommended reading---Unsigned_64 is defined for a specific programming context. Typically that of interfacing to 2**N bit addressable hardware, N >= 3. When a program does not perform any interfacing, but still uses types from Interfaces, then in a sense its use of type is close to C's approach to the fundamental type system: In C, you have fundamental "scalar" types that say, "at least that many bits, some operations, some behavior at the bounds, and please look up the rest in the compiler's documentation". When Ada allows the programmer to work at a higher level of type isolation and expressiveness, without loosing any performance, not having to consult compiler docs, isn't this a win? I recall a c.l.ada message from a university teacher of embedded systems programming (model trains, I think) whose classes had switched from C to Ada. After that, the students had achieved more and got better results. The effect was attributed to Ada's fundamental type system and types defined in terms of the (abstracted) problem domain. I.e., not just Interfaces. > In <32e35e5a-3cae-4fdc-be4a-3ae1e146e9f3@l64g2000hse.googlegroups.com>, Adam Beneschan writes: >> Of course, it really doesn't matter which one you use (except, >> perhaps, to help prevent incorrect type conversions). The only >> differences have to do with readability, pedagogy, and helping make >> your programs self-documenting. But ever since Ada was designed, the >> position of the Ada community has been that it's better to avoid using >> the standard numeric types provided by Ada (Integer, Float) and define >> your own that explicitly include the numeric range you need. You seem >> to be going in the opposite direction, by recommending that this user >> use a standard type provided by the language rather than defining his >> own (although the standard type you recommend is certainly better >> defined than Integer or Float). >> >> Another issue is that an implementation doesn't have to provide >> Interfaces.Unsigned_64. It should be present on any target processor >> whose addressable unit is an 8-bit byte or a 16-, 32-, or 64-bit >> word. But I've seen processors in the past that use 6-bit characters >> or 36-bit words, and in those cases, using Unsigned_64 instead of "mod >> 2**64" will turn a portable program into a nonportable one. I'll >> grant that such processors are rare these days. >> >> -- Adam >> > -- Georg Bauhaus Y A Time Drain http://www.9toX.de