Re: Prefix to 'ACCESS must either statically match... But why?

Re: Prefix to 'ACCESS must either statically match... But why?

[Grein, Christoph]

> Objects of Stream_Element_Array ( 1 .. 3 ) have no bounds stored, the bounds 
are 
> known at compile time.

I should have said: Bounds are known at elaboration time. Here they are also 
known at compile time.

Re: Prefix to 'ACCESS must either statically match... But why?

[Wojtek Narczynski]

Theoretically all clear, practically - major bummer.

Looks like this used to work in some older version of GNAT:

 type String_Access is access all String;
 S : aliased String (1 .. 10);

...

  declare
    subtype S_Access is String_Access (S'Range);
    SA : S_Access := S'Access;
  begin

(From this thread:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right
&th=1de133c02ad2b2d3&seekm=m3ogiofyua.fsf%40mheaney.ni.net#link1)

But now it doesn't with current (3.15p) GNAT nor current Aonix. Other 
variants I could think of don't work either.

At present I can't come up with any idea on how to obtain a compatible 
access subtype.

Regards,
Wojtek

Re: Prefix to 'ACCESS must either statically match... But why?

[James S. Rogers]

If you want to use a more general access to string try using an access
to an unbounded string. See the following:

-- Array Access Test
with Ada.Text_Io;
with Ada.Strings.Unbounded;
use Ada.Strings.Unbounded;

procedure Array_Access_Test is
   type String_Access is access all String;
   type Unbounded_Access is access all Unbounded_String;
   procedure Print (
         Item : in     String_Access ) is
   begin
      Ada.Text_Io.Put_Line(Item.All);
   end Print;
   procedure Print(Item : in Unbounded_Access) is
   begin
      Ada.Text_Io.Put_Line(To_String(Item.All));
   end Print;

   Name  : aliased String           := "Jim Rogers";
   Name2 : aliased Unbounded_String := To_Unbounded_String ("Jim Rogers");
   Sa    : String_Access;
   Ua    : Unbounded_Access;
begin

   Sa := Name'access;
   Print(Sa);
   Ua := Name2'access;
   Print(Ua);
end Array_Access_Test;

Passing around an access to an unbounded string has none of the limitations
you are finding with fixed strings. You do not create a new subtype for the
unbounded string type whenever you create an instance. The subtype is
always constant.

Jim Rogers
"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0301270746.6ad4c4b0@posting.google.com...
> Theoretically all clear, practically - major bummer.
>
> Looks like this used to work in some older version of GNAT:
>
>  type String_Access is access all String;
>  S : aliased String (1 .. 10);
>
> ...
>
>   declare
>     subtype S_Access is String_Access (S'Range);
>     SA : S_Access := S'Access;
>   begin
>
> (From this thread:
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right
> &th=1de133c02ad2b2d3&seekm=m3ogiofyua.fsf%40mheaney.ni.net#link1)
>
> But now it doesn't with current (3.15p) GNAT nor current Aonix. Other
> variants I could think of don't work either.
>
> At present I can't come up with any idea on how to obtain a compatible
> access subtype.
>
> Regards,
> Wojtek

Re: Prefix to 'ACCESS must either statically match... But why?

[Wojtek Narczynski]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message news:<PriZ9.6187$rq4.561874@bgtnsc05-news.ops.worldnet.att.net>...

> If you want to use a more general access to string try using an access
> to an unbounded string. See the following:

Uhm, I switched to String from Stream_Element_Array because the old
GNAT code example used it. In my project there is something like this:

 subtype Content_Length_Type is 
    Stream_Element_Count range 0 .. 2 ** 16 - 1;
 subtype Padding_Length_Type 
    is Stream_Element_Count range 0 .. 2 ** 8 - 1;

 type Content_Type
    ( Content_Length : Content_Length_Type; 
    Padding_Length : Padding_Length_Type ) 
 is record    
   Content : aliased Stream_Element_Array( 1..Content_Length );
   case Padding_Length is
      when 0 => null;
      when others => Padding : Stream_Element_Array( 1..Padding_Length
);
   end case;       
 end record;


First I read a header with Content_Length and Padding_Length from
socket, then I use declare to read the actual content in another
syscall.

Then I wanted to pass the access to Content to a function that accepts
access Stream_Element_Array as its parameter. Looks like this cannot
be done though.

And in general I find the inablility to declare access type subtypes
in parallel with the subtypes for the designated type obstructive.

Thanks,
Wojtek

Re: Prefix to 'ACCESS must either statically match... But why?

[James S. Rogers]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0301271851.7c907f60@posting.google.com...
> "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:<PriZ9.6187$rq4.561874@bgtnsc05-news.ops.worldnet.att.net>...
>
> > If you want to use a more general access to string try using an access
> > to an unbounded string. See the following:
>
> Uhm, I switched to String from Stream_Element_Array because the old
> GNAT code example used it. In my project there is something like this:
>
>  subtype Content_Length_Type is
>     Stream_Element_Count range 0 .. 2 ** 16 - 1;
>  subtype Padding_Length_Type
>     is Stream_Element_Count range 0 .. 2 ** 8 - 1;
>
>  type Content_Type
>     ( Content_Length : Content_Length_Type;
>     Padding_Length : Padding_Length_Type )
>  is record
>    Content : aliased Stream_Element_Array( 1..Content_Length );
>    case Padding_Length is
>       when 0 => null;
>       when others => Padding : Stream_Element_Array( 1..Padding_Length
> );
>    end case;
>  end record;
>
>
> First I read a header with Content_Length and Padding_Length from
> socket, then I use declare to read the actual content in another
> syscall.
>
> Then I wanted to pass the access to Content to a function that accepts
> access Stream_Element_Array as its parameter. Looks like this cannot
> be done though.

Why are you choosing to pass an access to a Stream_Element_Array
instead of just the Stream_Element_Array? Avoiding the use of an
access type would also eliminate the problem. Remember that any
parameter, even an IN parameter can be passed by reference by the
compiler. In fact, an array object is most frequently passed by reference.

>
> And in general I find the inablility to declare access type subtypes
> in parallel with the subtypes for the designated type obstructive.

It appears that you are thinking in C while programming in Ada.

Jim Rogers

Re: Prefix to 'ACCESS must either statically match... But why?

[Wojtek Narczynski]

> Why are you choosing to pass an access to a Stream_Element_Array
> instead of just the Stream_Element_Array? Avoiding the use of an
> access type would also eliminate the problem. Remember that any
> parameter, even an IN parameter can be passed by reference by the
> compiler. In fact, an array object is most frequently passed by 
> reference.

Because this function uses 'Unrestricted_Access to return an array of
accecceses to slices of the parameter array. This is supposed to yeld
in better speed and compactness, and let me avoid heap allocations. If
I were to copy the strings out of this huge array I'd have to allocate
them on heap.

>> And in general I find the inablility to declare access type
>> subtypes in parallel with the subtypes for the designated 
>> type obstructive.
> 
> It appears that you are thinking in C while programming in Ada.

Heh, maybe. Please take a look at my other post - even the compilers
are unsure if what I've written is Ada ;-)

Thanks,
Wojtek

Re: Prefix to 'ACCESS must either statically match... But why?

[James S. Rogers]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0301280414.6ac8d45e@posting.google.com...
> > Why are you choosing to pass an access to a Stream_Element_Array
> > instead of just the Stream_Element_Array? Avoiding the use of an
> > access type would also eliminate the problem. Remember that any
> > parameter, even an IN parameter can be passed by reference by the
> > compiler. In fact, an array object is most frequently passed by
> > reference.
>
> Because this function uses 'Unrestricted_Access to return an array of
> accecceses to slices of the parameter array. This is supposed to yeld
> in better speed and compactness, and let me avoid heap allocations. If
> I were to copy the strings out of this huge array I'd have to allocate
> them on heap.

Since this is a parameter array, why not merely return an array of
index pairs? The index pairs can index the beginning and end of
each array slice.

The idea of returning a set of "pointers" to pieces of an array is
very common in C, where pointer arithmetic is tied to array
indexing. In Ada there is no corresponding tie between access
types and array indexing. If you want an index, then use an
index. This difference between C and Ada is made easier to
use due to Ada's array slicing capabilities, which are not
directly implemented in C.

>
> >> And in general I find the inablility to declare access type
> >> subtypes in parallel with the subtypes for the designated
> >> type obstructive.
> >
> > It appears that you are thinking in C while programming in Ada.
>
> Heh, maybe. Please take a look at my other post - even the compilers
> are unsure if what I've written is Ada ;-)

Jim Rogers

Re: Prefix to 'ACCESS must either statically match... But why?

[Wojtek Narczynski]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message news:<hGwZ9.19365$zF6.1390291@bgtnsc04-news.ops.worldnet.att.net>...
 
> Since this is a parameter array, why not merely return an array of
> index pairs? The index pairs can index the beginning and end of
> each array slice.

That's rigth! I haven't thought about it. Thanks!

> The idea of returning a set of "pointers" to pieces of an array is
> very common in C

Please note that an access to array slice is by no means less safe
than an access to the whole array. Thus I wish Ada had them.

Thanks for your help!

Regards,
Wojtek

Re: Prefix to 'ACCESS must either statically match... But why?

[James S. Rogers]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0301281220.448bc12e@posting.google.com...
> "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:<hGwZ9.19365$zF6.1390291@bgtnsc04-news.ops.worldnet.att.net>...
>
> > Since this is a parameter array, why not merely return an array of
> > index pairs? The index pairs can index the beginning and end of
> > each array slice.
>
> That's rigth! I haven't thought about it. Thanks!
>
> > The idea of returning a set of "pointers" to pieces of an array is
> > very common in C
>
> Please note that an access to array slice is by no means less safe
> than an access to the whole array. Thus I wish Ada had them.
>

I agree that an access to an array slice is just as safe.
I was merely trying to help you learn the Ada approach to this
kind of a problem. I was trying to explain why the C and Ada
approaches are different.

Jim Rogers

Re: Prefix to 'ACCESS must either statically match... But why?

[tmoran]

> the Ada approach
with Ada.Text_Io;
procedure Testas is

  type Index_Pairs is record
    Left, Right : Natural := 0;
  end record;

  type Index_Pair_Lists is array (1 .. 4) of Index_Pairs;

  procedure Target_Proc(A, B, C, D : in String) is
  begin
    Ada.Text_Io.Put_Line(D & C & B & A);
  end Target_Proc;

  procedure Pass_It_On(S    : in String;
                       List : in Index_Pair_Lists) is
  begin
    Target_Proc(S(List(1).Left .. List(1).Right),
                S(List(2).Left .. List(2).Right),
                S(List(3).Left .. List(3).Right),
                S(List(4).Left .. List(4).Right));
  end Pass_It_On;

  Test_String: constant String := "now is the time";

  function Find_Substrings(Source : String) return Index_Pair_Lists is
  begin
    return ((1, 3), (5, 6), (8, 10), (12, 15)); -- fake it
  end Find_Substrings;

begin
  Pass_It_On(Test_String, Find_Substrings(Test_String));
end Testas;

Re: Prefix to 'ACCESS must either statically match... But why?

[Wojtek Narczynski]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message 

> I was merely trying to help you learn the Ada approach to this
> kind of a problem. I was trying to explain why the C and Ada
> approaches are different.

So you did, thanks!

Regards,
Wojtek

Re: Prefix to 'ACCESS must either statically match... But why?

[Grein, Christoph]

> > No, that model is absolutely wrong!
> 
> Well, I never said I am perfect.

But are you present? Or even future?

Re: Prefix to 'ACCESS must either statically match... But why?

[Grein, Christoph]

> RM 3.3.1(8): The _subtype_indication_ or full type definition of an 
> _object_declaration_ defines the nominal subtype of the object. The 
> _object_declaration_ declares an object of the type of the nominal subtype.
> 
> > AR1 : aliased Stream_Element_Array := ( 2, 4, 5 );
> 
> AR1 nominal subtype is Stream_Element_Array (<>) of type 
> Stream_Element_Array (<>)
> 
> > AR2 : aliased Stream_Element_Array ( 1 .. 3 ) := ( 2, 4, 5 );
> 
> AR2 nominal subtype is Stream_Element_Array (1 .. 3) of type 
> Stream_Element_Array (<>)
> 
> > 
> > AR1A : Stream_Element_Array_access := AR1'access;
> > 
> > -- Illegal
> > AR2A : Stream_Element_Array_access := AR2'access;
> > 
> > 
> RM/TC1 3.10.2 (24): ... The view denoted by the prefix X shall satisfy 
> the following additional requirements, presuming the expected type for 
> the X'Access is the general access type A with designated type D:
> 
> RM/TC1 3.10.2 (27/1): ...; if D is untagged, then the type view shall be 
> D, and A's designated subtype either statically match the nominal 
> subtype of the view or be discriminanted and unconstrained.
> 
> A = Stream_Element_Array_Access
> D = Stream_Element_Array (<>)
> 
> D - untagged; type of both view is Stream_Element_Array (<>) = D; and 
> A's designated subtype (Stream_Element_Array (<>)) is discriminanted and 
> unconstrained.
>
> What's wrong?

This is my exegesis. I admit, the whole theme is quite obscure...

AR1 nominal subtype Stream_Element_Array, constrained by initial value to actual 
subtype Stream_Element_Array (1 .. 3).

AR2 nominal and actual subtype Stream_Element_Array (1 .. 3).

So for AR1, nominal subtypes statically match, for AR2, they don't.
It's the nominal subtypes that have to match, not the actual ones.

See RM 3.3.1(8,9), 3.10(10), 3.10.2(27/1), 4.9.1(2).

Gnat 3.16w seems to have a problem here.

Re: Prefix to 'ACCESS must either statically match... But why?

[Grein, Christoph]

> GNAT supports access to array slices with 'Unrestricted_Access, It
> will be an interesting experiment to check how it behaves on
> sub-storage unit ranges.

So I'd like to hear if and when you have results of these experiments. I'm not sure that the 
Gnat doc says it will return sensible values in this case.

Re: Prefix to 'ACCESS must either statically match... But why?

[Grein, Christoph]

> Please note that an access to array slice is by no means less safe
> than an access to the whole array. Thus I wish Ada had them.

I'm not so sure that this is possible in general. Note that the slice boundaries need no lie on storage 
unit boundaries.

Re: Prefix to 'ACCESS must either statically match... But why?

[Wojtek Narczynski]

"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message news:<mailman.7.1043823456.30820.comp.lang.ada@ada.eu.org>...

> I'm not so sure that this is possible in general. Note that the slice 
> boundaries need no lie on storage unit boundaries.

The same is true for, say, a packed array of three boolean elements.
AFAIK Pragma Pack excludes the eligibility of aliased for element. Or
opposite - aliased element of Pragma Pack.

GNAT supports access to array slices with 'Unrestricted_Access, It
will be an interesting experiment to check how it behaves on
sub-storage unit ranges.

Regards,
Wojtek

Re: Prefix to 'ACCESS must either statically match... But why?

[Grein, Christoph]

> > Could somebody please explain me why is this rule present? I find it
> > very limting. Is this because AR2 bounds are not stored with the
> > object?
> > 
> > Type Stream_Element_Array_access is access all Stream_Element_Array;
> > 
> > AR1 : aliased Stream_Element_Array := ( 2, 4, 5 );
> > AR2 : aliased Stream_Element_Array ( 1 .. 3 ) := ( 2, 4, 5 );
> > 
> > AR1A : Stream_Element_Array_access := AR1'access;
> > 
> > -- Illegal
> > AR2A : Stream_Element_Array_access := AR2'access;
> > 
> > 
> > LRM:3.10.2(27), The nominal subtype of the prefix to 'ACCESS or
> > 'UNCHECKED_ACCESS must either statically match the designated subtype
> > of the expected type or the designated subtype must be discriminated
> > and unconstrained, Continuing
> 
> Well I am a Ada-beginner myself so I might be wrong, but as far as I
> understand strictly typed languages in general "Stream_Element_Array ( 1 .. 3 
)" is a
> new anonymous type which ist not a Stream_Element_Array anymore. A bit like 
typing
> 
> Type Stream_Element_Array_AR2 is new Stream_Element_Array ( 1 .. 3 );
> AR2 : aliased Stream_Element_Array_AR2 := ( 2, 4, 5 );

No, that model is absolutely wrong!

Stream_Element_Array ( 1 .. 3 ) is a subtype of Stream_Element_Array, not a new 
type derived from it.

The difference is that Stream_Element_Array is unconstrained, 
Stream_Element_Array ( 1 .. 3 ) is constrained.

Objects of Stream_Element_Array have their bounds stored.
Objects of Stream_Element_Array ( 1 .. 3 ) have no bounds stored, the bounds are 
known at compile time.

Stream_Element_Array_access is an access type to the unconstrained (first named 
subtype) Stream_Element_Array, so its objects cannot point to objects of the 
constrained subtype.

So they do not statically match.

Re: Prefix to 'ACCESS must either statically match... But why?

[Martin Krischik]

On Mon, 27 Jan 2003 07:41:34 +0100, Grein, Christoph wrote:

>> Type Stream_Element_Array_AR2 is new Stream_Element_Array ( 1 .. 3 );
>> AR2 : aliased Stream_Element_Array_AR2 := ( 2, 4, 5 );
 
> No, that model is absolutely wrong!

Well, I never said I am perfect.

> Stream_Element_Array ( 1 .. 3 ) is a subtype of Stream_Element_Array, not a new 
> type derived from it.

> The difference is that Stream_Element_Array is unconstrained, 
> Stream_Element_Array ( 1 .. 3 ) is constrained.

Thanks for clarifying this point.

Regards.

Martin

-- 
Martin Krischik
mailto://Martin@krischik.com
http://ada.krischik.com

Re: Prefix to 'ACCESS must either statically match... But why?

[Jeffrey Carter]

Grein, Christoph wrote:
> 
> Objects of Stream_Element_Array have their bounds stored.
> Objects of Stream_Element_Array ( 1 .. 3 ) have no bounds stored, the bounds are 
> known at compile time.

Whether an implementation stores the bounds of an array subtype is not 
specified by the ARM. Nothing prevent an implement from not storing the 
bounds of an object of an unconstrained subtype nor from storing the 
bounds of a constrained subtype, provided that all operations of array 
subtypes work properly.

-- 
Jeff Carter
"C++ is like giving an AK-47 to a monk, shooting him
full of crack and letting him loose in a mall and
expecting him to balance your checking account
'when he has the time.'"
Drew Olbrich

Prefix to 'ACCESS must either statically match... But why?

[Wojtek Narczynski]

Hello,

Could somebody please explain me why is this rule present? I find it
very limting. Is this because AR2 bounds are not stored with the
object?

Type Stream_Element_Array_access is access all Stream_Element_Array;

AR1 : aliased Stream_Element_Array := ( 2, 4, 5 );
AR2 : aliased Stream_Element_Array ( 1 .. 3 ) := ( 2, 4, 5 );

AR1A : Stream_Element_Array_access := AR1'access;

-- Illegal
AR2A : Stream_Element_Array_access := AR2'access;


LRM:3.10.2(27), The nominal subtype of the prefix to 'ACCESS or
'UNCHECKED_ACCESS must either statically match the designated subtype
of the expected type or the designated subtype must be discriminated
and unconstrained, Continuing


Thanks,
Wojtek

Re: Prefix to 'ACCESS must either statically match... But why?

[Martin Krischik]

On Sat, 25 Jan 2003 14:31:17 +0000, Wojtek Narczynski wrote:

> Path:
> 	news.t-online.com!newsmm00.sul.t-online.com!newsfeed01.sul.t-online.de!t-on
> 	line.de!newsfeed.stueberl.de!logbridge.uoregon.edu!newsfeed.stanford.edu!po
> 	stnews1.google.com!not-for-mail
> Message-ID: <5ad0dd8a.0301251431.6370c6bc@posting.google.com>
> From: wojtek@power.com.pl (Wojtek Narczynski)
> Newsgroups: comp.lang.ada
> Subject: Prefix to 'ACCESS must either statically match... But why?
> Date: 25 Jan 2003 14:31:17 -0800
> Lines: 25
> Organization: http://groups.google.com/
> NNTP-Posting-Host: 212.160.20.107
> X-Trace: posting.google.com 1043533877 23863 127.0.0.1 (25 Jan 2003 22:31:17
> 	GMT)
> X-Complaints-To: groups-abuse@google.com
> NNTP-Posting-Date: 25 Jan 2003 22:31:17 GMT
> Xref: linux1.krischik.com comp.lang.ada:581
> MIME-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 8bit
> 
> 
> Hello,
> 
> Could somebody please explain me why is this rule present? I find it
> very limting. Is this because AR2 bounds are not stored with the
> object?
> 
> Type Stream_Element_Array_access is access all Stream_Element_Array;
> 
> AR1 : aliased Stream_Element_Array := ( 2, 4, 5 );
> AR2 : aliased Stream_Element_Array ( 1 .. 3 ) := ( 2, 4, 5 );
> 
> AR1A : Stream_Element_Array_access := AR1'access;
> 
> -- Illegal
> AR2A : Stream_Element_Array_access := AR2'access;
> 
> 
> LRM:3.10.2(27), The nominal subtype of the prefix to 'ACCESS or
> 'UNCHECKED_ACCESS must either statically match the designated subtype
> of the expected type or the designated subtype must be discriminated
> and unconstrained, Continuing

Well I am a Ada-beginner myself so I might be wrong, but as far as I
understand strictly typed languages in general "Stream_Element_Array ( 1 .. 3 )" is a
new anonymous type which ist not a Stream_Element_Array anymore. A bit like typing

Type Stream_Element_Array_AR2 is new Stream_Element_Array ( 1 .. 3 );
AR2 : aliased Stream_Element_Array_AR2 := ( 2, 4, 5 );

Hope it helps

Martin

-- 
Martin Krischik
mailto://Martin@krischik.com
http://www.ada.krischik.com

Re: Prefix to 'ACCESS must either statically match... But why?

[Vadim Godunko]

Wojtek Narczynski wrote:
> 
> Could somebody please explain me why is this rule present? I find it
> very limting. Is this because AR2 bounds are not stored with the
> object?
> 
> Type Stream_Element_Array_access is access all Stream_Element_Array;
> 

RM 3.3.1(8): The _subtype_indication_ or full type definition of an 
_object_declaration_ defines the nominal subtype of the object. The 
_object_declaration_ declares an object of the type of the nominal subtype.

> AR1 : aliased Stream_Element_Array := ( 2, 4, 5 );

AR1 nominal subtype is Stream_Element_Array (<>) of type 
Stream_Element_Array (<>)

> AR2 : aliased Stream_Element_Array ( 1 .. 3 ) := ( 2, 4, 5 );

AR2 nominal subtype is Stream_Element_Array (1 .. 3) of type 
Stream_Element_Array (<>)

> 
> AR1A : Stream_Element_Array_access := AR1'access;
> 
> -- Illegal
> AR2A : Stream_Element_Array_access := AR2'access;
> 
> 
RM/TC1 3.10.2 (24): ... The view denoted by the prefix X shall satisfy 
the following additional requirements, presuming the expected type for 
the X'Access is the general access type A with designated type D:

RM/TC1 3.10.2 (27/1): ...; if D is untagged, then the type view shall be 
D, and A's designated subtype either statically match the nominal 
subtype of the view or be discriminanted and unconstrained.

A = Stream_Element_Array_Access
D = Stream_Element_Array (<>)

D - untagged; type of both view is Stream_Element_Array (<>) = D; and 
A's designated subtype (Stream_Element_Array (<>)) is discriminanted and 
unconstrained.


What's wrong?


Vadim Godunko