Re: unsigned type

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

anon schrieb:
> For Strings:
>                           --  'A' is a zero length string, A'Last = 0, and
>                           --  put_line  ( A ( A'First .. A'Last ) ) ;
>                           --  does not raise an Constraint_Error even though in  
>                           --  this case it translate to:
>                           --  put_line  ( A ( 0 .. 0 ) ) ; 
>   A : String := ""        ; 
> 
> Since you can have zero length string , the index is Natual instead of Positive, 
> because zero is in Natural but is not define in Positive. Even though the 
> Standard package define String index as a Positive type. (GNAT)

(It is slightly confusing, I think, to say that in a
definition like

   type String is array (Positive range <>) of Character;

the index type is Natural. It's not Natural in the Ada sense;
that fact that many String related subprograms use the Natural
subtype emphasizes the presence of Natural in String handling,
but does not turn subtype Positive into index type Natural,
does it?)

> Always use standards, those who do not are the one making the mistakes 
> that others must correct to make the program portable during updating. 

How is it possible for _any_ implementation defined type
to be portable just because the standard says it is
implementation defined? (Like Standard.Integer?)

For example, the GNU Ada Database Environment uses a 64 bit
type available with GNAT.  This type may well be impossible when
using other compilers.

   type SQLBIGINT    is range -(2 ** 63) .. +(2 ** 63) - 1;
   for SQLBIGINT'Size use 64;

How will a subtype of Long_Long_Integer be different?
Long_Long_Integer may not be provided at all. Or it
does not have 64 bits.  I don't see how to gain anything
with subtyping or deriving from the predefined integer
types in cases such as this one.

Using a subtype, there is more opportunity for
shooting yourself in the foot when you use them
where you should have been using database integers.
A more striking example has been outlined by Tom Moran.

Any Ada compiler can immediately decide whether or not this
library unit can be translated (ported) when it sees SQLBIGINT.
Seems perfectly clear, uses standard conforming type definitions,
and explicitly stating what is needed.  Wouldn't this be much
more implicit and more diffuse if the developers had tried to
force database integers to be standard integers?