Re: String filtering

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccu0fya3c3.fsf@shell01.TheWorld.com...
...
> And there's some run-time overhead for access parameters -- they carry
> run-time accessibility-level info with them.

That's not just an overhead issue, but also potentially a safety issue, as
the accessibility checks are done at run-time. Sometimes you need that, but
the result is that the location of the call determines whether or not
Program_Error is raised -- which means that only testing (rather than the
Ada compiler) will ferret out problems. Wheras the same code with an in out
parameter would be illegal (and have no run-time overhead). Much better from
a safety perspective.

To give an example (using procedures so it's legal Ada code):

     type T is tagged ...;
     type AT is access all T;

     procedure P1 (O : in out T) is
        P : AT := O'access; -- Illegal, accessibility fails.
     begin
        ....
     end P1;

     procedure P2 (O : access T) is
       P : AT := O; -- Might raise Program_Error, depending on the point of
the call.
     begin
       ...
     end P2;

     Obj : T;
     Obj2 : aliased T; -- Extra aliased needed here, even though it has no
effect.

     P1 (Obj);
     P2 (Obj2'Access); -- Extra 'Access here, even though the code is
essentially the same.

Using access parameters clutters both the objects and the call site, adds
run-time overhead, and in Ada 200Y, even might add null checks (unless you
hadd even more clutter with "not null" in the parameter declaration).

And what's the difference? For a tagged type, the code generated (and the
evaluation order issues) for "in out" and "access" are essentially
identical, but one is allowed and the other isn't. Makes lots of sense.

> Furthermore, there's (annoyingly) no way to declare a formal parameter
> aliased.  So you use 'access' where 'in out' should suffice, or you
> declared tagged types that have no need for a tag.

There are no such types. :-) [OK, I'm kidding, but there certainly aren't
many such types.]

> Yes, there are workarounds for the lack of [in] out params on functions
> -- but they have global consequences on your code.

Yes,  indeed.

                        Randy.