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-Thread: 103376,ee887b7593f7961b X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada OS based on Minix3 Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1pmkcuemqczer.j2i34pvc2lne$.dlg@40tude.net> <81912719-8c66-439d-a40e-529b22acd8a6@u29g2000pro.googlegroups.com> <14t6hwu8udm8j$.1x339y69m2ew1.dlg@40tude.net> <14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net> Date: Thu, 13 Nov 2008 18:28:45 +0100 Message-ID: <192kzxoa5qgu3.170vbwrazvhvp.dlg@40tude.net> NNTP-Posting-Date: 13 Nov 2008 18:28:46 CET NNTP-Posting-Host: b09e27f2.newsspool4.arcor-online.net X-Trace: DXC=:8A\0WhRj6YFm0Y?OE@2^X4IUK On Wed, 12 Nov 2008 18:58:33 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net... > ... >>>> 5. Getting a pool-specific pointer to the object upon >>>> initialization/finalization, when the object is allocated in such a >>>> pool. >>>> (Unchecked_Conversion is really nasty there) >>> >>> I think you mean Unchecked_Access -- Unchecked_Conversion is not >>> necessary. >>> >>> I don't see how this can make sense. In Initialize or Finalize, you >>> don't know whether the object is in a pool, nor which pool. So how can >>> you get a pool-specific pointer? >> >> That is exactly the problem. Consider objects allocated on a user-defined >> pool. The object are linked into some list. When a new object is created >> the "constructor" places it into the list. When the object is destroyed, >> the "destructor" removes it. For both, you need a self-pointer, but you >> cannot get it from an "in out" parameter. > > Sorry, but this is completely wrong. This is *exactly* how Claw works, and > it works fine with Ada 95. It is perfectly OK to get a pointer from a > parameter of a tagged object. You do have to use 'Unchecked_Access, but that > is no problem if you are using Finalize to clean up. No, that does not work with pool-specific types: with Ada.Finalization; package Test_Unchecked is type T is new Ada.Finalization.Limited_Controlled with private; overriding procedure Initialize (X : in out T); overriding procedure Finalize (X : in out T); private type T_Ptr is access T'Class; type T is new Ada.Finalization.Limited_Controlled with null record; Global : T_Ptr; end Test_Unchecked; procedure Initialize (X : in out T) is begin Add_To_List (Global, X'Unchecked_Access); -- Illegal, general access is required, but T_Ptr is expected end Initialize; And it is error-prone. There should be nothing "unchecked" there. If access type had its own initialization/finalization hooks at appropriate places, we could move that stuff where it actually belongs to. After all, you could have: type T_Pool_1_Ptr is access T'Class; for T_Pool_1_Ptr'Storage_Pool use Pool_1; Global_1 : T_Pool_1_Ptr; type T_Pool_2_Ptr is access T'Class; for T_Pool_2_Ptr'Storage_Pool use Pool_2; Global_2 : T_Pool_2_Ptr; Objects allocated in Pool_1 are placed into Global_1 list. Objects allocated in Pool_2 are in Global_2. Object initialization is just a wrong place to manipulate these lists. > Most of the rest of the stuff that you and Bob have talked about is too > incompatible to consider for Ada. I strongly disagree. I see no incompatibilities. I think that proper construction can be added without changing existing language behaviour. Even Ada.Finalization can be left as-is. Return statements and functions returning limited objects were IMO much more obtrusive. "not null" stuff was plainly incompatible with Ada 95. Nevertheless they were accepted. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de