assigning record address using access, w/unconstrained array

assigning record address using access, w/unconstrained array

[Technobabble]

Greetings,

The following is the code I've got a gnat error with.  This code is
relation to the previous array RANGE questions I've had.

--File: test_pkg.ads
package test_pkg is

--Types:
 type xyz_array is array (integer range <>) of integer;   -- this is it

 type xyz_array_pointer is access all xyz_array;

 type xyz_array_pointer_array is array (1..100) of xyz_array_pointer;


 type Object is
     record
        XYZ : xyz_array_pointer_array;    
        abc : integer;
     end record;

-- declarations:
 xyz5_array : aliased xyz_array := (1..5 => 0);

 procedure my_range (This : in Object); 

end test_pkg;

---------------------
--File: test_pkg.adb
package body test_pkg is

  procedure my_range (This : in Object) is
  begin 
                This.XYZ(1) := xyz5_array'ACCESS;  
--       rangexyz :=  This.XYZ(1)'RANGE;

  end my_range;
end test_pkg;

--------------------

GNAT produces the following error after compiling test_pkg.adb:

test_pkg.adb:18:17: assignment to "in" mode parameter not allowed


******

After I comment out the suspect line:
                This.XYZ(1) := xyz5_array'ACCESS;  -- address of xyz_array
type is assigned

and put a null in the procedure 'my_range' it compiles fine. As for the
RANGE attribute, well I just have not been able to get to it yet since the
line above it bombs.


******


HELP !!

thanks,
Richmond
therionics@computer.org

Re: assigning record address using access, w/unconstrained array

[Tucker Taft]

Technobabble (WishList@2600.com) wrote:

: The following is the code I've got a gnat error with.  This code is
: relation to the previous array RANGE questions I've had.

: --File: test_pkg.ads
: package test_pkg is

: --Types:
:  type xyz_array is array (integer range <>) of integer;   -- this is it

:  type xyz_array_pointer is access all xyz_array;

:  type xyz_array_pointer_array is array (1..100) of xyz_array_pointer;


:  type Object is
:      record
:         XYZ : xyz_array_pointer_array;    
:         abc : integer;
:      end record;

: -- declarations:
:  xyz5_array : aliased xyz_array := (1..5 => 0);

:  procedure my_range (This : in Object); 

: end test_pkg;

: ---------------------
: --File: test_pkg.adb
: package body test_pkg is

:   procedure my_range (This : in Object) is

***>>>                         ^^ "in out" should solve your problem.

:   begin 
:                 This.XYZ(1) := xyz5_array'ACCESS;  
: --       rangexyz :=  This.XYZ(1)'RANGE;

:   end my_range;
: end test_pkg;

: --------------------

: GNAT produces the following error after compiling test_pkg.adb:

: test_pkg.adb:18:17: assignment to "in" mode parameter not allowed

As well it should.  Just change the parameter mode to "in out" if you
want the procedure to update its parameter.

: ...
: thanks,
: Richmond
: therionics@computer.org

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

Re: assigning record address using access, w/unconstrained array

[Technobabble]

Greetings Tucker,

Thanks !!! I'll catch on eventually. You're the best !!


> : ---------------------
> : --File: test_pkg.adb
> : package body test_pkg is
> 
> :   procedure my_range (This : in Object) is
> 
> ***>>>                         ^^ "in out" should solve your problem.
> 
> :   begin 
> :                 This.XYZ(1) := xyz5_array'ACCESS;  
> : --       rangexyz :=  This.XYZ(1)'RANGE;
> 
> :   end my_range;
> : end test_pkg;
> 
> : --------------------
> 
> : GNAT produces the following error after compiling test_pkg.adb:
> 
> : test_pkg.adb:18:17: assignment to "in" mode parameter not allowed
> 
> As well it should.  Just change the parameter mode to "in out" if you
> want the procedure to update its parameter.
> 
thanks,
Richmond
therionics@computer.org

Re: assigning record address using access, w/unconstrained array

[dewarr]

In article <WishList-1909982010140001@a11.phoenix-13.goodnet.com>,
  WishList@2600.com (Technobabble) wrote:
> Greetings,
>
> The following is the code I've got a gnat error with.  This code is
> relation to the previous array RANGE questions I've had.
>
> --File: test_pkg.ads
> package test_pkg is
>
> --Types:
>  type xyz_array is array (integer range <>) of integer;   -- this is it
>
>  type xyz_array_pointer is access all xyz_array;
>
>  type xyz_array_pointer_array is array (1..100) of xyz_array_pointer;
>
>  type Object is
>      record
>         XYZ : xyz_array_pointer_array;
>         abc : integer;
>      end record;
>
> -- declarations:
>  xyz5_array : aliased xyz_array := (1..5 => 0);
>
>  procedure my_range (This : in Object);
>
> end test_pkg;
>
> ---------------------
> --File: test_pkg.adb
> package body test_pkg is
>
>   procedure my_range (This : in Object) is
>   begin
>                 This.XYZ(1) := xyz5_array'ACCESS;
> --       rangexyz :=  This.XYZ(1)'RANGE;
>
>   end my_range;
> end test_pkg;
>
> --------------------
>
> GNAT produces the following error after compiling test_pkg.adb:
>
> test_pkg.adb:18:17: assignment to "in" mode parameter not allowed
>
> ******
>
> After I comment out the suspect line:
>                 This.XYZ(1) := xyz5_array'ACCESS;  -- address of xyz_array
> type is assigned
>
> and put a null in the procedure 'my_range' it compiles fine. As for the
> RANGE attribute, well I just have not been able to get to it yet since the
> line above it bombs.
>
> ******
>
> HELP !!
>
> thanks,
> Richmond
> therionics@computer.org


This is a VERY fundamental misunderstanding. I really think
you need to try to sit down and carefully read a text book
on Ada rather than trying to learn it experimentally by
seeing what works. The use of IN mode to represent pass
by value is fundamental, and of course you cannot try to
modify the parameter in this case, as your code most
obviously does.

You may be able to write small programs without fundamental
understanding, but you will get into big trouble when you
try to scale up.

Actually this particular misunderstanding is quite odd,
since in C, the ONLY parameter passing mechanism is by
value, so this "restriction" [which is really more like
a fundamental mechanism of the language] should be familiar.

People will tell you of course to switch from using mode
IN to using mode IN OUT, but if you simply add an OUT
keyword to your subprogram declaration thinking "that's
another odd keyword I don't understand", you will begin
to get yourself into a very confused state!

It is very definitely the fashion in programming languages
to use complex languages such as C++ without really
understanding everything they use (how many C++ programmers
really understand Koenig lookup -- do I remember the name
correctly?)

I am always surprised to see Ada 95 code in which all kinds
of extremely complex features of the language are used with
gay abandon in very complicated combinations. When I look at
such code I know one of two things, either

  (a) the programmer knows Ada far better than I do
  (b) the programmer does not know EXACTLY what they are doing

usually the explanation is (b)!

For me, the way to deal with complexity is to learn what you
need, and use a rather small subset of the language. This
does not translate into saying that Ada should be much
smaller, since one persons subset is different from anothers.
Remember that C.A.R. Hoare in his (in)famous Turing address
on Ada agreed that "it is possible to select a safe and
realiable subset of Ada" [I am not sure of the exact wording]
and so presumably would be perfectly comfortable writing
Ada by sticking to his subset that meets his requirements.

We stick to a small subset of GNAT in writing the GNAT
compiler itself and it works just fine for us. People who
know C or Pascal find they can read the code with very
little effort, and most importantly, the folks in the
GNAT group can understand one another's code immediately.
I often find that in undisciplined environments, you get
various people in the group using different complex
contortions. The author may more or less understand the
contortion, but other people in the group do not, further
adding to the problem of exclusive code protection ("Ask
Al, he's the only one who understands that part of the code")


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