access type referencing nested array element

access type referencing nested array element

[Technobabble]

Greetings,

Anyone know the syntax for referencing an array element (record) from an
access type pointing to an array of records ?


pointer -> array of records -> record

type xyz_rec is 
    record
      a : integer;
      b : integer;
    end record;

type xyz_array is array (1 .. 100) of xyz_rec;
type xyz_pointer is access xyz_array;


Here is my guess assuming that I want to get the 5th record in an array:
XYZ    :  xyz_pointer;
MY_XYZ :  xyz_rec;

assuming that the pointer XYZ has been assigned to an array of records .....

MY_XYZ := XYZ.xyz_array'(5);  or maybe

MY_XYZ := XYZ.xyz_array'(5).all;     or maybe I'm just guessing too much.


help..........

Thanks,
Richmond

Re: access type referencing nested array element

[Dale Stanbrough]

Technobabble wrote:

> Anyone know the syntax for referencing an array element (record) from an
> access type pointing to an array of records ?



   XYZ (5).a -- implicit dereferencing
   XYZ.all (5).a -- explicit dereferencing


Dale

Re: access type referencing nested array element

[Technobabble]

Greetings Dale,

> > Anyone know the syntax for referencing an array element (record) from an
> > access type pointing to an array of records ?
> 
> 
> 
>    XYZ (5).a -- implicit dereferencing
>    XYZ.all (5).a -- explicit dereferencing
> 
> 
> Dale

Ok, that means that if XYZ is a pointer to array of records, I can simply
use the pointer with the array index eg. (5) to access the 5th record. 
Now if I want to get the address of the 5th record would this be correct:

type xyz is access xyz_rec;

XYZ_POINTER := XYZ (5)'access;

????

thanks.
Richmond

Re: access type referencing nested array element

[Tucker Taft]

Technobabble (WishList@2600.com) wrote:

: Ok, that means that if XYZ is a pointer to array of records, I can simply
: use the pointer with the array index eg. (5) to access the 5th record. 
: Now if I want to get the address of the 5th record would this be correct:

: type xyz is access xyz_rec;

: XYZ_POINTER := XYZ (5)'access;

Yes, presuming the array is declared an an array of *aliased* components.

E.g.:

   type array_of_rec is array(Positive range <>) of aliased xyz_rec;
                                                    ^^^^^^^
                     This is required if you want to use 'Access.

: ????

: thanks.
: Richmond

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: access type referencing nested array element

[dewarr]

In article <EzJ5Gp.JG5.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Technobabble (WishList@2600.com) wrote:
>
> : Ok, that means that if XYZ is a pointer to array of records, I can simply
> : use the pointer with the array index eg. (5) to access the 5th record.
> : Now if I want to get the address of the 5th record would this be correct:
>
> : type xyz is access xyz_rec;
>
> : XYZ_POINTER := XYZ (5)'access;
>
> Yes, presuming the array is declared an an array of *aliased* components.
>
> E.g.:
>
>    type array_of_rec is array(Positive range <>) of aliased xyz_rec;
>                                                     ^^^^^^^
>                      This is required if you want to use 'Access.
>


Indeed, and that helps explain why I advise not using the
access attribute AT ALL. Aliasing is in general a bad thing.
General pointers were excluded from Ada 83 for very good
reasons. They were added in Ada 95 for good, but very narrow
reasons (the most convincing argument was the need to be
able to statically initialize structures containing pointers)

BUT! Once this features is there it is subject to horrible
misuse. I find the undisciplined use of pointers and access
to be the data analog of gotos. As you all know, I don't have
a rule that absolutely forbids gotos, and I do not suggest a
rule that absolutely forbids the use of access. Indeed any
rule that absolutely forbids the use of any feature in Ada
is highly suspect (every feature in Ada was put there for a
purpose, if you think a given feature is so useless that it
should never be used, you are probably missing something).

However, just as we teach students never to use goto, so
that they can discover how to properly strucure programs
in the usual case, we should teach them never to use 'Access
so they can learn how to properly structure their data in
the usual case.

In particular, the horrible phenomenon of people importing
a C style into Ada 95 is something I often see, with the
aliased keyword all over the place. Perfectly dreadful
coding style!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: access type referencing nested array element

[Brian Rogoff]

On Sat, 19 Sep 1998 dewarr@my-dejanews.com wrote:
> 
> In particular, the horrible phenomenon of people importing
> a C style into Ada 95 is something I often see, with the
> aliased keyword all over the place. Perfectly dreadful
> coding style!

I suspect that you wouldn't like the C++ STL, or the Ada translations of 
it, since they tend to use "aliased" a lot (in the Ada case of course; in 
C++ everything is potentially aliased) and I think you couldn't write an 
STL in Ada without it. I agree completely with your admonition against its 
(over)use, but I'm awfully glad its there. 

-- Brian

Re: access type referencing nested array element

[Dale Stanbrough]

Robert Dewar wrote...
 
" In particular, the horrible phenomenon of people importing
  a C style into Ada 95 is something I often see, with the
  aliased keyword all over the place. Perfectly dreadful
  coding style!"


But of course a better style is to silenty do a 'Unrestricted_Access
deep inside your code (a'la Gnat.Spitbol :-)


Dale

Re: access type referencing nested array element

[dewarr]

In article <dale-2009981033240001@dale.ppp.cs.rmit.edu.au>,
  dale@cs.rmit.edu.au (Dale Stanbrough) wrote:
> Robert Dewar wrote...
>
> " In particular, the horrible phenomenon of people importing
>   a C style into Ada 95 is something I often see, with the
>   aliased keyword all over the place. Perfectly dreadful
>   coding style!"
>
> But of course a better style is to silenty do a 'Unrestricted_Access
> deep inside your code (a'la Gnat.Spitbol :-)
>
> Dale


Absolutely! No one is saying don't use these features at all.
You use features like this when you absolutely have to.
Certainly burying nasty uses inside an abstraction is exactly
the right usage.

There are two cases in which 'Unrestricted_Access is used
in connection with the SPITBOL interface.

First, in conjunction with the A * B notation used to
represent the A $ B notation of SPITBOL. An important part
of the design of this package is to mimic the syntax and
style of SPITBOL (note that this is similar to the use that
Brian just alluded to in the Ada port of STL).

Second, if you want to use nested procedures in connection
with immediate assignment in SPITBOL pattern structures that
are global objects, then there is no choice but to use the
'Unrestricted_Access attribute. You can of course decide for
yourself to limit the utility of the package by avoiding this
usage.

I think we all understand both the fact that procedure
pointers are very limited in Ada (though of course not
MORE limited than C/C++ where there is no nesting anyway).
We also understand the reasons for this decision.

Whether you want this limitation to apply to your use of the
SPITBOL interface is up to you of course.

But in a way this comment here gets to the crux of the
matter. The many (in my opinion silly) contributions to the
recent discussion of gotos show how easy it is for people to
make the switch from:

  "this feature is to be avoided, don't use it when there
   are equally good or better alternatives"

to

  "this feature should never be used"

That shift is almost ALWAYS a horrible mistake. If anyone
reads what I am saying about 'Access and aliased and rushes
off and puts into their coding guidelines absolute rules
against using these features, they are ignorant nitwits!
Better that you allow completely free use than hobble the
language with restrictions of this kind.

For the Ada 95 design as it stands, both the aliased keyword
and the 'Access attribute are essential ingrediants. Their
removal at this stage would badly damage the language.

If you cannot see that the previous paragraph is completely
consistent with my statements that discourage the use of
these features, you are missing a VERY important point.

In particular, the idea that you can prove that someone I am
being inconsistent by finding a use of these features in my
code is completely absurd.

It is like deciding that you don't believe that N. Wirth
understands that gotos are a bad thing because you discovered
that in his text book he uses a single goto in his code for
heapsort!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: access type referencing nested array element

[Tucker Taft]

I responded earlier:

: Technobabble (WishList@2600.com) wrote:

: : Ok, that means that if XYZ is a pointer to array of records, I can simply
: : use the pointer with the array index eg. (5) to access the 5th record. 
: : Now if I want to get the address of the 5th record would this be correct:

: : type xyz is access xyz_rec;
                     ^^^ insert "all" here

: : XYZ_POINTER := XYZ (5)'access;

: Yes, presuming the array is declared an an array of *aliased* components.

As indicated above, I forgot to mention that you need to say
"access all" rather than simply "access" if you want to use 'Access 
to create values of your access type.  Without the "all", you can
only use an allocator (new xyz_rec...) to create values of your
access type.

: E.g.:

:    type array_of_rec is array(Positive range <>) of aliased xyz_rec;
:                                                     ^^^^^^^
:                      This is required if you want to use 'Access.

: : ????

: : thanks.
: : Richmond

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company