From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8a402d78988bdf2b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-24 08:57:50 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: [announcement] SYSAPI and SYSSVC for Windows Date: 24 Dec 2003 11:57:49 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1072285069 25004 192.74.137.185 (24 Dec 2003 16:57:49 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 24 Dec 2003 16:57:49 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:3782 Date: 2003-12-24T11:57:49-05:00 List-Id: "Dmitry A. Kazakov" writes: > Robert A Duff wrote: > > > "Dmitry A. Kazakov" 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