access_to_constant as subprogram paramater

access_to_constant as subprogram paramater

[nelson]

Why does the language disallow an access_to_constant as a parameter
to a subprogram?

For example:

--
-- Example illustrating desire to pass access_to_constant to a procedure.
-- Refer to RM 3.10(12) and 6.1.
--
procedure Access_Parameter is

   PathName : aliased constant String := "/a/b/c.adb";
      -- Declared as constant in order to produce compilation error


   procedure Parse (Input : access String) is
--
-- Would like to declare this:
--    procedure Parse (Input : access constant String) is
-- as Parse never modifies the input string
--
   begin
      null;  -- Parse a pathname string into components
   end Parse;

begin
   Parse(PathName'Access);  -- line 22
end Access_Parameter;



for which gnat produces:


cd /usr/nelson/example/
gnatmake -c access_parameter.adb
gcc -c access_parameter.adb
access_parameter.adb:22:10: access-to-variable designates constant
gnatmake: "access_parameter.adb" compilation error

Compilation exited abnormally with code 2 at Sat Sep 19 13:23:25

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

Re: access_to_constant as subprogram paramater

[Tucker Taft]

nelson@blaze-net.com wrote:

: Why does the language disallow an access_to_constant as a parameter
: to a subprogram?

At the time of the design, we didn't have a compelling-enough
reason to include this capability.  Personally, I was a little
concerned that using "access constant" for access-to-constant
parameters, but simply "access" (instead of "access all") for
access-to-variable parameters would also confuse people.  In retrospect,
I wish we had included the access-to-constant parameters, but
it doesn't seem like a very big deal either way.

In any case, you can just use a named access-to-constant
type in many cases, or even simpler, a plain old "IN" parameter.

: For example:

: --
: -- Example illustrating desire to pass access_to_constant to a procedure.
: -- Refer to RM 3.10(12) and 6.1.
: --
: procedure Access_Parameter is

:    PathName : aliased constant String := "/a/b/c.adb";
:       -- Declared as constant in order to produce compilation error


:    procedure Parse (Input : access String) is
: --
: -- Would like to declare this:
: --    procedure Parse (Input : access constant String) is
: -- as Parse never modifies the input string
: --
:    begin
:       null;  -- Parse a pathname string into components
:    end Parse;

: begin
:    Parse(PathName'Access);  -- line 22
: end Access_Parameter;

What's wrong with "Input : in String"?  That seems by far the
simpler approach in a case like this, and no need to use that
gnarly "'Access" at all.

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

Re: access_to_constant as subprogram paramater

[David C. Hoos, Sr]

nelson@blaze-net.com wrote in message <6u0pmf$rvk$1@nnrp1.dejanews.com>...

<snip>
Here's the way to do what you want:

procedure Access_Parameter is

   Pathname : aliased constant String := "/a/b/c.adb";
   -- Declared as constant in order to produce compilation error

   type Constant_String_Access_Type is access constant String;

   procedure Parse (Input : Constant_String_Access_Type) is
      --
      -- Would like to declare this:
      -- procedure Parse (Input : access constant String) is
      -- as Parse never modifies the input string
      --
   begin
      null; -- Parse a pathname string into components
   end Parse;

begin
   Parse (Pathname'Access);
end Access_Parameter;

David C. Hoos, Sr.

Re: access_to_constant as subprogram paramater

[dewarr]

In article <6u0pmf$rvk$1@nnrp1.dejanews.com>,
  nelson@blaze-net.com wrote:
>
>
> Why does the language disallow an access_to_constant as a parameter
> to a subprogram?
>
> For example:
>
> --
> -- Example illustrating desire to pass access_to_constant to a procedure.
> -- Refer to RM 3.10(12) and 6.1.
> --
> procedure Access_Parameter is
>
>    PathName : aliased constant String := "/a/b/c.adb";
>       -- Declared as constant in order to produce compilation error
>
>    procedure Parse (Input : access String) is
> --
> -- Would like to declare this:
> --    procedure Parse (Input : access constant String) is
> -- as Parse never modifies the input string
> --
>    begin
>       null;  -- Parse a pathname string into components
>    end Parse;
>
> begin
>    Parse(PathName'Access);  -- line 22
> end Access_Parameter;
>
> for which gnat produces:
>
> cd /usr/nelson/example/
> gnatmake -c access_parameter.adb
> gcc -c access_parameter.adb
> access_parameter.adb:22:10: access-to-variable designates constant
> gnatmake: "access_parameter.adb" compilation error
>
> Compilation exited abnormally with code 2 at Sat Sep 19 13:23:25


The real question here is why are you using an access parameter in any case.
I think that access parameters tend to be very much overused. In your example,
why on earth not just pass the string as an in parameter?


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

Re: access_to_constant as subprogram paramater

[dewarr]

In article <EzJo6C.5EC.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> In any case, you can just use a named access-to-constant
> type in many cases, or even simpler, a plain old "IN" parameter.

Very good advice. Let me state a definite rule:

NEVER use an access mode parameter if you can use a normal
IN or IN OUT mode parameter in its place.

People have got into a LOT of trouble ignoring this rule.
For example, some of the early versions of the Intermetrics
bindings done for Ada 95 were peppered with incorrect uses
of access parameters to model C pointers. This doesn't work
because nearly all the routines expected to be able to deal
with null values for the parameters, and there is of course
no way to pass a null value to an access parameter (if you
think you can simply use NULL as the actual, then it shows
a mismatch between your conception of the language feature
and the actual feature that is there -- that indeed is the
worst feature of this Ada construct, it invites this
mismatch!)

The proper way to model a C pointer is (how amazing!) with
an Ada access value for which pragma Convention (C) is given.
Most likely you don't need the pragma Convention, but if you
are being hyper-correct it should be there.

Note that you generally cannot pass a pointer-to-unconstrained
backwards and forwards to C, for the simple reason that this
type corresponds to nothing at all in C.


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