Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion unsigned type
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Georg Bauhaus  
View profile  
 More options Jun 29 2009, 6:25 am
Newsgroups: comp.lang.ada
From: Georg Bauhaus <rm.dash-bauh...@futureapps.de>
Date: Mon, 29 Jun 2009 12:25:14 +0200
Local: Mon, Jun 29 2009 6:25 am
Subject: Re: unsigned type
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?


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.