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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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 03:15:01 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!p62.246.194.83.tisdip.tiscali.DE!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: [announcement] SYSAPI and SYSSVC for Windows Date: Wed, 24 Dec 2003 12:20:45 +0100 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: p62.246.194.83.tisdip.tiscali.de (62.246.194.83) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1072264500 12310244 62.246.194.83 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:3777 Date: 2003-12-24T12:20:45+01:00 List-Id: Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> Ekkehard Morgenstern wrote: > >> > so I could've just used a tagged limited record? >> > >> > Like this: >> > >> > type T is tagged limited >> > record >> > A : My_Array_Type; >> > end record; >> > >> > procedure F ( O : in out T ) is >> > Ptr : My_Array_Cell_Ptr; >> > begin >> > Ptr := O.A(1)'Access; >> > end; >> > >> > Right? >> >> No. It is unrelated. The thing you are getting access of has to be >> aliased. So it is the array elements which has to be, for example: >> >> type T is limited private; >> private >> type Integer_Array is array (Integer range <>) of aliased Integer; >> type T is limited record >> A : Integer_Array (1..3); >> end record; >> >> 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. Then it is a good style to always write 'Access first, and then to try to understand why it does not compile. Because if it does not, that probably indicates a potential design problem. > The point is: when you say 'Access, the compiler can prove that you > don't have dangling pointers. Otherwise, you need 'Unchecked_Access > (but then you better prove it yourself, or your program might do bad > things). Yes. >> If the array elements be tagged, then you would need not write "aliased" >> in the array declaration. > > That's not quite right. Tagged *parameters* (like O in the above > example) are automatically aliased. But other objects are aliased only > if declared so (by the "aliased" keyword) or if allocated in the heap by > "new" (whether tagged or not). Formally yes, but techincally it is no matter. One can always circumvent this silly limitation (after all the tagged elements of an array remain tagged!). So: type Element is tagged ... type Element_Ptr is access all Element; type Container is array (Integer range <>) of Element; -- Elements are aliased even if not specified X : Container (1..3); X_Ptr : Element_Ptr; ... X_Ptr := X (1)'Unchecked_Access; -- Illegal But this is OK: procedure Get_Ptr (E : in out Element; P : out Element_Ptr) is begin P := E'Unchecked_Access; end Get_Ptr; Get_Ptr (X (1), X_Ptr); -- This is fine! > IMHO, it was a mistake to make tagged parameters automatically aliased. Agree. But this was rather a consequence of the idea of view conversions, that was the mistake, IMO. > 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) 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. 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); -- (:-)) 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. > Summary: To get an access value to an existing object, you must first > make sure it's aliased (which means allocated on the heap, explicitly > declared "aliased", or a tagged parameter). Then you must worry about > accessibility level (which determines whether you should use 'Access or > 'Unchecked_Access). -- Merry Christmas! Dmitry A. Kazakov www.dmitry-kazakov.de