Re: [announcement] SYSAPI and SYSSVC for Windows

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Robert A Duff wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> >>    procedure F (O : in out T ) is
> >>    begin
> >>        ... O.A(1)'Access; -- This is OK, A(i) are aliased
> > 
> > No, that's not quite good enough.  The parameter O is considered to be
> > nested within F, so you need 'Unchecked_Access instead of 'Access here.
> > Whenever you use 'Unchecked_Access, you have to make sure you don't
> > use dangling pointers -- so the & operator in C or C++ is more like
> > 'Unchecked_Access than 'Access in that regard.
> 
> It depends on the target, which was not specified.

Good point.  If the access type is nested inside F, then 'Access will
work.  That's pretty unusual, in my experience -- almost all types,
including access types, are declared at library level.

> Then it is a good style to always write 'Access first, and then to try to
> understand why it does not compile.

I suppose that's a reasonable thing to do.  You don't want to use
'Unchecked_Access when you could use 'Access -- it's like crying wolf.

>... Because if it does not, that probably
> indicates a potential design problem.

Sometimes, but there are certainly many cases where you want to make a
pointer to a more-nested thing.  You just have to remember to get rid of
the pointer before it causes trouble, just like in C or C++.  One
technique is to use Limited_Controlled -- Initialize hooks the object
into some global data structure, and Finalize takes it out.  That's
relatively safe.

> > We should, instead, have allowed the "aliased" keyword on parameters.
> 
> No, I think that "aliased" should better be used as a type qualifier:
> 
> type X is aliased tagged ...; -- This is a by-reference type
> type X is tagged ...; -- The compiler is free to choose
>                       -- (with all the consequences)

We're not (just) talking about whether parameters are passed by
reference.  We're (also) talking about whether regular variables are
aliased.  It seems to me somewhat dangerous, and deserving of a special
mark on the variable declaration.  (It wasn't allowed at all in Ada 83.)

> For parameters there are access types. IMO it is a bad idea to get pointers
> to parameters, if that is really needed one should pass a pointer instead.

I think I agree with that, but then you trip over another design mistake
-- there's no such thing as an "access constant" parameter.

> A good example is Finalize. There is a nasty problem to get a pointer to
> the parameter of Finalize, because there is no way to figure out which pool
> it should be. For by-reference types it should be sort of:
> 
> procedure Finalize (Object : access not all Object_Type); -- (:-))

I'm not sure what you mean.  How does this tell you what pool Object is
in (maybe none!)?

> Then I would disallow overloading like this:
> 
> procedure Foo (Object : access Object_Type);
> procedure Foo (Object : in out Object_Type);
> 
> Instead of this I would make access types transparent to primitive
> operations, as they are to array indexing and record member extraction.

We proposed something like that (implicit .all) in the early stages of
the Ada 9X project.

I actually don't like implicit dereference at all, even for selected
components.  But the problem is that .all is so verbose and ugly, it
*needs* to be implicit.  If it were up to me, the syntax for dereference
would be Pointer^ (from Pascal), which is unobtrusive, but still makes
the dereference explicit.  Following a pointer and selecting a record
component is semantically much different from just selecting a record
component -- the syntax should convey that.

- Bob