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, T_FILL_THIS_FORM_SHORT autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.unit0.net!peer02.am4!peer.am4.highwinds-media.com!peer03.fr7!futter-mich.highwinds-media.com!news.highwinds-media.com!fx27.am4.POSTED!not-for-mail From: Felix Krause Newsgroups: comp.lang.ada Message-ID: <2017072721305951845-contact@flyx.org> References: <2017072417413775878-contact@flyx.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Smart Pointers and Tagged Type Hierarchies User-Agent: Unison/2.2 X-Complaints-To: abuse@eweka.nl NNTP-Posting-Date: Thu, 27 Jul 2017 19:30:58 UTC Organization: Eweka Internet Services Date: Thu, 27 Jul 2017 21:30:59 +0200 X-Received-Body-CRC: 3333944629 X-Received-Bytes: 5802 Xref: news.eternal-september.org comp.lang.ada:47521 Date: 2017-07-27T21:30:59+02:00 List-Id: On 2017-07-24 19:53:54 +0000, Dmitry A. Kazakov said: > On 2017-07-24 17:41, Felix Krause wrote: > >> Now I am wondering what others think of these approaches. Are there >> alternatives? Which one would be better from a user perspective? > > I am using generic pointer (Handle), which can be instantiated later > with any derived type from the base reference counting type. See Simple > Components: > > http://www.dmitry-kazakov.de/ada/components.htm#Objects_etc > > This is your second approach but with object pointer type passed as a > second generic parameter. > > generic > type Object_Type (<>) is abstract new Entity with private; > type Object_Type_Ptr is access Object_Type'Class; > package Object.Handle is > type Handle is new Ada.Finalization.Controlled with private; > > Users of smart pointer need not to be generic. I don't know why you > think it is necessary. Using your types, let's say I have type Entity_Access is access Entity'Class; package Entity_Handle is new Object.Handle (Entity, Entity_Access); type A_Type is new Entity with private; type A_Access is access A_Type'Class; package A_Handle is new Object.Handle (A_Type, A_Access); Now some subroutine wants to take an Entitiy as parameter, or more precisely, a Handle to an Entity. If I specify this: procedure Do_Something (E : Entity_Handle.Handle); I cannot call this procedure with an A_Handle.Handle. So I'd need to do: generic with package Actual_Handle is new Object.Handle (<>); procedure Do_Something (E : Actual_Handle.Handle); I don't see how I can prevent this using your approach. > Regarding hierarchy of types and additional operations and the problem > of exposing the implementation type. You can use delegation: > > E.g. if you have your File_Stream_Object and File_Stream_Reference, you > define a File_Stream_Interface: > > type File_Stream_Interface is interface; > procedure Foo (Stream : in out File_Stream_Interface) is abstract; > > Then both object and reference implement the interface: > > type File_Stream_Object is > new Instance and File_Stream_Interface ... > overriding procedure Foo (Stream : in out File_Stream_Reference); > > type File_Stream_Reference is > new Reference and File_Stream_Interface ... > overriding procedure Foo (Stream : in out File_Stream_Reference); > > From second Foo you call the first after dereferencing. Now you can > hide File_Stream_Object and expose only File_Stream_Interface and > File_Stream_Reference. You can also derive from File_Stream_Object and > File_Stream_Reference adding new interfaces. The latter has a drawback > that you will have to convert pointer to a more specific class. > > ------------------------------------ > It is quite tedious because: > > 1. Delegation cannot be automated in Ada; > 2. Pointer are not promoted upon inheritance. > > Otherwise this schema works well. Thanks for this. It is probably not the approach I will use, but not a bad idea. Another question using generics: If I do use a generic package for the smart pointers, is there a good way to put the instance of that package inside the package that defines the derived type? Example (starts with the generic code in my original post): package Stream is type Instance is abstract limited tagged private; -- fetches an event from the stream procedure Fetch (Object : in out Instance; Ret : out Event) is abstract; private type Instance is abstract tagged limited record Refcount : Natural := 1; end record; end Stream; generic type Implementation is new Stream.Instance with private; package Stream.Smart is type Reference is new Ada.Finalization.Controlled with private; -- reference-counting implementation overriding procedure Adjust (Object : in out Reference); overriding procedure Finalize (Object : in out Reference); private type Implementation_Access is access all Implementation'Class; type Reference is new Ada.Finalization.Controlled with record Data : access Implementation_Access; end record; end Stream.Smart; package File_Stream is type Instance is new Stream.Instance with private; package Smart is new Stream.Smart (Instance); private type Instance is new Stream.Instance with record File : Ada.Text_IO.File_Access; end record; end File_Stream; This does not compile because I cannot instantiate Stream.Smart with the incomplete File_Stream.Instance type. What would work is to have instead a child package: package File_Stream.Smart is new Stream.Smart (File_Stream.Instance); But with this, I am not able to define any subroutines in the File_Stream package that take a smart pointer. -- Regards, Felix Krause