Question: Combination of Access and Constraining

Question: Combination of Access and Constraining

[Papandopulo]

Small Ada question:

I need one function to accept
an array of unknown size of Boolean,
so I declare type and function:

type Tp is array (Positive range <>) of Boolean;
type Tp_Access is access all Tp;

function Fn (Arg : in Tp_Access) return Natural;

Now I try to call it with the constrained array:

declare
  type TpCon is new Tp(1..1);
  Arr : aliased TpCon;
begin
  Arr(1) := True;
  Res := Fn (Arr'Access);
end;

Compiler says on the invocation line:
expected type: Tp_Access defined at ...
found type TpCon defined at ...

I think that access to constrained
type should be convertible to access
to unconstrained type.

So where I am going wrong here ?

Thanx,
George

Re: Question: Combination of Access and Constraining

[tmoran]

>   type TpCon is new Tp(1..1);
>
> expected type: Tp_Access defined at ...
> found type TpCon defined at ...
Ada is serious about types.  Try
  Arr : aliased Tp := (1 .. 1 =>True);

I presume there's a good reason you go to all this trouble with
access types, instead of just saying
  function Fn (Arg : Tp) return Natural;
  Arr : Tp(1 .. 1);
begin
  Arr(1) := True;
  Res := Fn (Arr);

Re: Question: Combination of Access and Constraining

[Dmitry A. Kazakov]

On 20 Feb 2003 00:06:15 -0800, papand0pul0@yahoo.com (Papandopulo)
wrote:

>Small Ada question:
>
>I need one function to accept
>an array of unknown size of Boolean,
>so I declare type and function:
>
>type Tp is array (Positive range <>) of Boolean;
>type Tp_Access is access all Tp;
>
>function Fn (Arg : in Tp_Access) return Natural;

Pointers are inherently bad. Why not:

function Fn (Arg : Tp) return Natural;

>Now I try to call it with the constrained array:
>
>declare
>  type TpCon is new Tp(1..1);
                       ^^^^^^
But this is another type! Probably you meant a subtype:

subtype TpCon is Tp(1..1);

>  Arr : aliased TpCon;
>begin
>  Arr(1) := True;
>  Res := Fn (Arr'Access);
>end;
>
>Compiler says on the invocation line:
>expected type: Tp_Access defined at ...
>found type TpCon defined at ...
>
>I think that access to constrained
>type should be convertible to access
>to unconstrained type.
>
>So where I am going wrong here ?

You are mixing types and subtypes. If you want just to put a
constraint on a type, declare a constrained subtype.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Question: Combination of Access and Constraining

[Grein, Christoph]

> type Tp is array (Positive range <>) of Boolean;
> type Tp_Access is access all Tp;
> function Fn (Arg : in Tp_Access) return Natural;

This is not a primitive function of Tp.

> Now I try to call it with the constrained array:
> 
> declare
>   type TpCon is new Tp(1..1);

TpCon does not inherit Fn.

>   Arr : aliased TpCon;
> begin
>   Arr(1) := True;
>   Res := Fn (Arr'Access);
> end;

Why do you use access types?

Re: Question: Combination of Access and Constraining

[David C. Hoos, Sr.]

TpCon needs to be a subtype of Tp -- i.e.:
subtype TpCon is Tp (1 .. 1);
Now, your function call will work.

However, there's no need to define a subtype
explicitly.  Why not just say
Arr: aliased Tp (1 .. 1);

----- Original Message ----- 
From: "Papandopulo" <papand0pul0@yahoo.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: February 20, 2003 2:06 AM
Subject: Question: Combination of Access and Constraining


> Small Ada question:
> 
> I need one function to accept
> an array of unknown size of Boolean,
> so I declare type and function:
> 
> type Tp is array (Positive range <>) of Boolean;
> type Tp_Access is access all Tp;
> 
> function Fn (Arg : in Tp_Access) return Natural;
> 
> Now I try to call it with the constrained array:
> 
> declare
>   type TpCon is new Tp(1..1);
>   Arr : aliased TpCon;
> begin
>   Arr(1) := True;
>   Res := Fn (Arr'Access);
> end;
> 
> Compiler says on the invocation line:
> expected type: Tp_Access defined at ...
> found type TpCon defined at ...
> 
> I think that access to constrained
> type should be convertible to access
> to unconstrained type.
> 
> So where I am going wrong here ?
> 
> Thanx,
> George
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: Question: Combination of Access and Constraining

[Matthew Heaney]

papand0pul0@yahoo.com (Papandopulo) wrote in message news:<1d13e1b4.0302200006.70207b86@posting.google.com>...
> Small Ada question:
> 
> I need one function to accept
> an array of unknown size of Boolean,
> so I declare type and function:
> 
> type Tp is array (Positive range <>) of Boolean;
> type Tp_Access is access all Tp;
> 
> function Fn (Arg : in Tp_Access) return Natural;

Get rid of the access type:

function Fn (Arg : Tp) return Natural;

Re: Question: Combination of Access and Constraining

[Papandopulo]

> Pointers are inherently bad. Why not:
If they are ingerently bad why they are in
the language ?

> function Fn (Arg : Tp) return Natural;
I have to use access type here. Since this is
simplified example. I have function accepting
several such array arguments each of which is
optional (null).

> But this is another type! Probably you meant a subtype:
> 
> subtype TpCon is Tp(1..1);
Nope, now it says:
warning: aliased object has explicit bounds.

> >So where I am going wrong here ?
> 
> You are mixing types and subtypes. If you want just to put a
> constraint on a type, declare a constrained subtype.
Gives warnings as I said before: variable with constrained subtype
can't be aliased (any idea why?).

Thanx,
George.

Re: Question: Combination of Access and Constraining

[Dmitry A. Kazakov]

On 20 Feb 2003 07:20:27 -0800, papand0pul0@yahoo.com (Papandopulo)
wrote:

>> Pointers are inherently bad. Why not:
>If they are ingerently bad why they are in
>the language ?

Because there are cases where they have no better alternative.
Nevertheless pointers is a source of countless problems.

>> function Fn (Arg : Tp) return Natural;
>I have to use access type here. Since this is
>simplified example. I have function accepting
>several such array arguments each of which is
>optional (null).

You can overload functions with different profiles.
 
>> But this is another type! Probably you meant a subtype:
>> 
>> subtype TpCon is Tp(1..1);
>Nope, now it says:
>warning: aliased object has explicit bounds.

Right, the above was not for pointers.

>> >So where I am going wrong here ?
>> 
>> You are mixing types and subtypes. If you want just to put a
>> constraint on a type, declare a constrained subtype.
>Gives warnings as I said before: variable with constrained subtype
>can't be aliased (any idea why?).

Because you need bounds to pass with. So if you really want pointers
(instead of letting the compiler to do all the dirty work for you),
then you could go like this:

   type Tp is array (Positive range <>) of Boolean;

   -- This will hold the constraint all the time
   type Tp_Rec (Length : Natural) is record
      Data : Tp (1..Length);
   end record;

   -- This value will serve as a default
   No_Data : aliased Tp_Rec :=
      (Length => 0, Data => (others => False));

    -- Anonymous access is safer
   function Fn (Arg : access Tp_Rec := No_Data'Access) return Natural;

   -- Put a constraint on it
   subtype TpCon is Tp_Rec (1);

   Arr : aliased TpCon; -- This is OK
begin
   Arr.Data (1) := True;
   Res := Fn (Arr'Access);
end Test;

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Question: Combination of Access and Constraining

[Jeffrey Carter]

Papandopulo wrote:
>>Pointers are inherently bad. Why not:
> 
> If they are ingerently bad why they are in
> the language ?

"Inherently bad" is not how I would put. However, large-scale pointer 
use is known to be the source of a family of errors. Pointers are needed 
far less in Ada than in some other languages, and it is a good idea to 
avoid them when you can.

>>function Fn (Arg : Tp) return Natural;
> 
> I have to use access type here. Since this is
> simplified example. I have function accepting
> several such array arguments each of which is
> optional (null).

This is still not a requirement to use access types. You can still say

Null_Tp : constant Tp (1 .. 0) := (1 .. 0 => False);

function Fn (Arg1 : Tp := Null_Tp; Arg2 : Tp := Null_Tp; ...)
return Natural;

Here you have a function with several such array arguments, each of 
which is optional, and each of which is a null array if not explicitly 
specified:

Tp1 : Tp (1 ..    10) := ...;
Tp2 : Tp (1 .. 1_000) := ...;
X   : Natural;
...
X := Fn (Tp1);         -- All except Arg1 are null
X := Fn (Arg2 => Tp2); -- All except Arg2 are null
X := Fn (Tp2, Tp1);    -- All except Arg1 & Arg2 are null

and so on.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail

Re: Question: Combination of Access and Constraining

[Yuri]

Jeffrey Carter wrote:

> >>function Fn (Arg : Tp) return Natural;
> >
> > I have to use access type here. Since this is
> > simplified example. I have function accepting
> > several such array arguments each of which is
> > optional (null).
>
> This is still not a requirement to use access types. You can still say
>
> Null_Tp : constant Tp (1 .. 0) := (1 .. 0 => False);
>
> function Fn (Arg1 : Tp := Null_Tp; Arg2 : Tp := Null_Tp; ...)
> return Natural;
>
> Here you have a function with several such array arguments, each of
> which is optional, and each of which is a null array if not explicitly
> specified:
>
> Tp1 : Tp (1 ..    10) := ...;
> Tp2 : Tp (1 .. 1_000) := ...;
> X   : Natural;
> ...
> X := Fn (Tp1);         -- All except Arg1 are null
> X := Fn (Arg2 => Tp2); -- All except Arg2 are null
> X := Fn (Tp2, Tp1);    -- All except Arg1 & Arg2 are null

And how efficient will be eventual comparison/argument
passing code resulting from such Null_Tp constant? Is it going to be
one-instruction comparison in ASM or much more?

For access argument and null it probably will be just on-liner
comparison and one liner passing argument.

Just curious )

Yuri.

Re: Question: Combination of Access and Constraining

[Jeffrey Carter]

Yuri wrote:
> And how efficient will be eventual comparison/argument
> passing code resulting from such Null_Tp constant? Is it going to be
> one-instruction comparison in ASM or much more?

The answer is, a software engineer doesn't care. Until it is done in the 
most straightforward, readable, and understandable way, and measurement 
shows that the system does not meet its timing requirments, and analysis 
shows that the only way to meet those timing requirements is by dealing 
with these issues, it's not an issue. Since compilers are very good at 
dealing with these kinds of things, I doubt it will ever be an issue. 
Those who worry about such things with no evidence that they are 
problems are simply wasting the most expensive resource on the project.

Since the actual parameter for one of these arguments may be of any 
length between zero and Positive'Last, they are almost certainly passed 
by reference, so I don't see that it gains you anything in the parameter 
passing department over explicitly passing a reference.

As for comparison, I guess it depends on what you're doing. An explicit 
check would look something like

if Arg8347'Length = 0 then
    -- zero-length handling
else
    -- non-zero-length handling
end if;

If, as is likely, you simply ignore the null parameters, then it will 
probably look like

for I in Arg9387'range loop
    -- non-zero-length handling
end loop;

and the loop is not entered if the parameter is null. This should be 
more "efficient" than

if Arg9387 /= null then
    for I in Arg9387'range loop
       ...
    end loop;
end if;

> For access argument and null it probably will be just on-liner
> comparison and one liner passing argument.

Since access parameters often have accessability information and 
associated checks associated with them this may not be correct.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

Re: Question: Combination of Access and Constraining

[Yuri]

> Yuri wrote:
> > And how efficient will be eventual comparison/argument
> > passing code resulting from such Null_Tp constant? Is it going to be
> > one-instruction comparison in ASM or much more?
>
> The answer is, a software engineer doesn't care. Until it is done in the
> most straightforward, readable, and understandable way, and measurement
> shows that the system does not meet its timing requirments, and analysis
> shows that the only way to meet those timing requirements is by dealing
> with these issues, it's not an issue. Since compilers are very good at
> dealing with these kinds of things, I doubt it will ever be an issue.
> Those who worry about such things with no evidence that they are
> problems are simply wasting the most expensive resource on the project.

I agree mostly, but there could be projects where performance is critical.

If rate of processing is low than performance is no issue. But if say you
process
real-time video higher-performance processor may make project
cost-inefficient.

Yuri.

Re: Question: Combination of Access and Constraining

[Simon Wright]

Yuri <yuri@tsoft.com> writes:

> I agree mostly, but there could be projects where performance is
> critical.
> 
> If rate of processing is low than performance is no issue. But if
> say you process real-time video higher-performance processor may
> make project cost-inefficient.

Many programmes have some time-critical areas. But it's not common (in
my experience) for something like parameter passing style to have much
impact, unless it's completely bizarre (passing 1MB arreays by copy
would count as bizarre!) More often it's very localized, and better
algorithms will make much more difference.

Re: Question: Combination of Access and Constraining

[John R. Strohm]

Yuri, if you are processing real-time video, you HAVE to use a
high-performance processor.

Consider a typical CCD camera.  256x256 pixels x 30 frames/second.  You are
processing 1.9 million pixels per second.

A 320x240x30 Hz display processes 2.3 million pixels per second.

Usually, you get eaten alive just moving data through the processor.  The
typical CCD camera correction requires you to read three values (raw pixel,
gain, level) and write one (corrected pixel).  You're now looking at 8
million data values per second through your processor.

"Yuri" <yuri@tsoft.com> wrote in message news:3E56AE14.9B5F31A@tsoft.com...
> > Yuri wrote:
> > > And how efficient will be eventual comparison/argument
> > > passing code resulting from such Null_Tp constant? Is it going to be
> > > one-instruction comparison in ASM or much more?
> >
> > The answer is, a software engineer doesn't care. Until it is done in the
> > most straightforward, readable, and understandable way, and measurement
> > shows that the system does not meet its timing requirments, and analysis
> > shows that the only way to meet those timing requirements is by dealing
> > with these issues, it's not an issue. Since compilers are very good at
> > dealing with these kinds of things, I doubt it will ever be an issue.
> > Those who worry about such things with no evidence that they are
> > problems are simply wasting the most expensive resource on the project.
>
> I agree mostly, but there could be projects where performance is critical.
>
> If rate of processing is low than performance is no issue. But if say you
> process
> real-time video higher-performance processor may make project
> cost-inefficient.
>
> Yuri.
>

Re: Question: Combination of Access and Constraining

[Jeffrey Carter]

Simon Wright wrote:
> 
> Many programmes have some time-critical areas. But it's not common (in
> my experience) for something like parameter passing style to have much
> impact, unless it's completely bizarre (passing 1MB arreays by copy
> would count as bizarre!) More often it's very localized, and better
> algorithms will make much more difference.

Regardless of the timing requirements for the software, doing strange 
things in the software to try to "optimize" some aspect of it, before 
you know that doing it normally is really impacting the timing, is 
simply wasting resources.

If your compiler makes suboptimal parameter passing decisions and those 
are significant enough to impact the timing, you need to improve your 
compiler selection process, not screw up the code.

-- 
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus

Re: Question: Combination of Access and Constraining

[John R. Strohm]

It can.

Some years ago, I had occasion to do a pixel blob coloring routine, in C,
that did 8-way connectivity.  The first version used a subroutine.  Runtime
was absolutely unacceptable for the application.  The call/return and
parameter passing time dominated.  The second version used a C macro, and
was fast enough.

I used a macro because I wanted the source code to be HUMAN-READABLE.
Physically inlining the code, without the macro, would have been a lot less
readable.

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vd6lji3b8.fsf@smaug.pushface.org...
> Yuri <yuri@tsoft.com> writes:
>
> > I agree mostly, but there could be projects where performance is
> > critical.
> >
> > If rate of processing is low than performance is no issue. But if
> > say you process real-time video higher-performance processor may
> > make project cost-inefficient.
>
> Many programmes have some time-critical areas. But it's not common (in
> my experience) for something like parameter passing style to have much
> impact, unless it's completely bizarre (passing 1MB arreays by copy
> would count as bizarre!) More often it's very localized, and better
> algorithms will make much more difference.