Re: Problem using Ada.Text_IO.Modular_IO

[anon@anon.org (anon)]

But like the rest you miss the point.  "KNOW and USE your Ada System and 
stop wasting time reventing types or routines!"  And USE as much of the 
system as you can or it may not be there tomorrow, when you really need it!"


In <867127d8-3b21-40dd-bb76-f19cd349b21e@26g2000hsk.googlegroups.com>, petter_fryklund@hotmail.com writes:
>On 11 Juli, 14:16, a...@anon.org (anon) wrote:
>> I did not comment Adam's two paragraphs because I did not want to cut
>> him down.
>>
>> Now, UNISYS at one time used 9-bit/18/36-bits (power of 3) instead of
>> power of 2. But the norm for todays computers is base 2, that's is the
>> only reason the specs only use 2**N instead of including 3**N for UNISYS.
>>
>> If you look at RM B.2 (7-8) which suggest that if the "target architectur=
>e"
>> support N-bits words then the "implementation shall provide" that
>> defintion in both signed and modular types. [ I think Adam forgot to look
>> at that one. ] Since, most system today sopport 8/16/32 and 64-bit words
>> then the "Interfaces" package shall contain definitions for those words.
>> And since vendor has done the work for us, so why not use it.
>>
>> But my main point is that you should know what is in the packages on
>> the system that you are using and how they work. And if they save time
>> in creating a partition then use them.
>>
>> Plus, as for compatibility with other Ada vendors or future GNAT versions=
>,
>> well my talks with Adacore over the death of GLADE suggest that they do
>> not care for the term "compatibility " any more. =A0Also, if we do not us=
>e
>> each part of the GNAT Ada package it might disappear in the next
>> specification version of Ada. Which may come out sooner than we think,
>> just an idea that came from my talks with Adacore.
>>
>> In <48772c92$0$6601$9b4e6...@newsspool2.arcor-online.net>, Georg Bauhaus =
><see.reply...@maps.futureapps.de> writes:
>>
>>
>>
>> >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 >=3D 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". =A0When 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. =A0I.e., not just Interfaces.
>>
>> >> In <32e35e5a-3cae-4fdc-be4a-3ae1e146e...@l64g2000hse.googlegroups.com>=
>, Adam Beneschan <a...@irvine.com> writes:
>>
>> >>> Of course, it really doesn't matter which one you use (except,
>> >>> perhaps, to help prevent incorrect type conversions). =A0The only
>> >>> differences have to do with readability, pedagogy, and helping make
>> >>> your programs self-documenting. =A0But ever since Ada was designed, t=
>he
>> >>> position of the Ada community has been that it's better to avoid usin=
>g
>> >>> the standard numeric types provided by Ada (Integer, Float) and defin=
>e
>> >>> your own that explicitly include the numeric range you need. =A0You s=
>eem
>> >>> 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. =A0It should be present on any target process=
>or
>> >>> whose addressable unit is an 8-bit byte or a 16-, 32-, or 64-bit
>> >>> word. =A0But I've seen processors in the past that use 6-bit characte=
>rs
>> >>> or 36-bit words, and in those cases, using Unsigned_64 instead of "mo=
>d
>> >>> 2**64" will turn a portable program into a nonportable one. =A0I'll
>> >>> grant that such processors are rare these days.
>>
>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--=
> Adam
>>
>> >--
>> >Georg Bauhaus
>> >Y A Time Drainhttp://www.9toX.de- D=F6lj citerad text -
>>
>> - Visa citerad text -
>
>Well the word length on UNISYS (SPERRY) has nothing to do with power
>of three. A word could also be 6x6 bits. Or can, there are still some
>UNISYS equipment around.