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,bd1d347880390e54 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-18 02:53:57 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-042-049.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Type conversions on pool-specific access types Date: Sat, 18 Oct 2003 11:59:16 +0200 Organization: At home Message-ID: References: <7kukov45dif9p7u2ohu6ml29mu9cgu621o@4ax.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-042-049.arcor-ip.net (145.254.42.49) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1066470835 26671368 145.254.42.49 (16 [77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:1114 Date: 2003-10-18T11:59:16+02:00 List-Id: Nick Roberts wrote: > "Dmitry A. Kazakov" wrote in message > news:g5ksovoq9nkg0tb53rgrn40vjjl7l5cqkb@4ax.com... > >> > ... >> > declare >> > Ptr : Base_Ptr := new Derived; >> > begin >> > Foo(Ptr); >> >> Yes, in this case. But consider specialized containers of >> Derived descendants: >> >> procedure Derived_Specific (X : Derived); >> type Array_Of_Derived is array (...) of Derived_Ptr; >> >> Now you can call Derived_Specific on any element of >> Array_Of_Derived without an explicit type conversion. >> It is also type safe. If I have only Base_Ptr, I lose that >> advantage and forced to always work in the terms of >> the base type and what is worse, to make casts. > > In this situation, I suggest you declare: > > type Derived_Ptr is access Derived'Class; > type Array_Of_Derived is array (...) of Derived_Ptr; > > exactly as you suggest, so you can call: > > Derived_Specific( Array_Of_Derived(...).all ); > > If you now wish to call Foo for an object designated by a component of the > Array_Of_Derived array, you do indeed need to do a conversion. I think > this can be adequately achieved in Ada 95 by the use of an intermediate > general access type: > > type General_Base_Ptr is access all Base'Class; > procedure Foo (Object: in General_Base_Ptr); Which in effect just means that we abadon use of pool-specific access types. Say, we introduce the language design principle: "a program dealing with objects allocated in ONE pool should to remain valid after removing the word "all" in all access type declarations." Don't you think it would be a reasonable principle? [ Note that all nasty cases of 'Unchecked_Access are excluded by the one-pool-requirement. ] >> [Finalize should not deallocate Object] >> Theoretically true, but practically, consider a situation >> when objects have to be always allocated in a specific >> pool. For example, on a user-defined stack. Further each >> object has to remove itself from some list. It is made >> upon finalization. The problem is that in this case you >> cannot use the advantages of thin pool-specific pointers. > > I repeat that a controlled object should not attempt to deallocate itself > during its own finalisation. It is not what required. What is required is that the object could delete itself from a global list [of pointers] upon finalization. For this a pointer to the object is needed. So you have to get a pointer to the object [of a limited type of course]. This is impossible for pool-specific access types. And I see no solution for that. Here I mean not a work-around, but how to fix it in Ada design. First of all the anonymous access types are general-access types. Otherwise, one could try to define Finalize [Initialize] for limited controlled types as: procedure Finalize (Object_Ptr : access Object_Type); as opposed to procedure Finalize (Object_Ptr : access all Object_Type); But then the actual storage pool of Object_Ptr would not be statically known. So it would not work anyway. And it is too late of course. So the situation with pool-specific access types is pretty grim at the moment. Not to mention other problems with storage pools: 1. How to make a user-defined storage pool usable both concurrently and inside a protected operation? 2. How to have task-specific storage pools, when task are created dynamically? -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de