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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Running a preprocessor from GPS? Date: Fri, 31 Jul 2015 18:29:11 +0200 Organization: cbb software GmbH Message-ID: <1lc647oywjma3.5a7rzz5b0l5l.dlg@40tude.net> References: <2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com> <014427b1-ff7a-4a69-82e6-0330af77ed96@googlegroups.com> <91f88d79-197c-419f-84a8-908e05967a2c@googlegroups.com> <135c2b00-d13c-4f5d-a586-8aca442d363b@googlegroups.com> <87380683vc.fsf@adaheads.sparre-andersen.dk> <347c6be9-c918-4bc0-9494-c93cd6740def@googlegroups.com> <4cb32c40-f659-490d-bbb6-73585fc069e8@googlegroups.com> <1ktkfm2fakx3h.28azibg1gr7y.dlg@40tude.net> <80c91140-1bdc-49eb-ad93-04ba1c5241a2@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: ChlmA4XFxcJoDoqGdDSflw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:27269 Date: 2015-07-31T18:29:11+02:00 List-Id: On Fri, 31 Jul 2015 06:50:58 -0700 (PDT), EGarrulo wrote: > On Friday, July 31, 2015 at 1:02:03 PM UTC+2, Dmitry A. Kazakov wrote: >>> Apparently, the next version >>> of GNATCOLL will include an alternative implementation[1] that removes this >>> requirement. But this means that right now there is GNATCOLL.Refcount only. >> >> That will add a level of indirection as some other implementations do. I >> don't see much merits doing this. There are no cases you might wish to have >> another type as the base and furthermore it won't do any good anyway. > > I don't understand what you mean. A common case is when you have an existing > class that wraps a resource and thus you can't change its base class. > Therefore the only general solution is to use composition, not inheritance, for > reference counting; like this, for example: > > generic > type T is private; > package Shared_Accesses is > type Shared_Object is record > Reference_Count : Natural; > Object : T; > end record; 1. Shared_Object here is not in T'Class [and T is not a limited type]. You claimed that it would be of T. 2. This design need not to be generic. The implementation I posted is not. 3. Smart pointers are pretty much useless if T is not limited and definite. Change it to type T (<>) is limited private; and see what happens. >> Because the only usable pattern of using strong pointers is this: >> >> type Object_Interface is interface; >> -- define operations here >> procedure Foo (X : in out Object_Interface) is abstract; >> >> in private >> type Object_Implementation is >> new Reference_Counted and Object_Interface with ... >> -- implement operations here >> overriding procedure Foo (X : in out Object_Implementation); >> >> in public >> type Object is new Object_Interface with private; >> -- implement operations here >> overriding procedure Foo (X : in out Object); >> >> in private >> type Object_Implementation_Ptr is access Object_Implementation'Class; Should have been type Object_Implementation_Ptr is access Object_Interface'Class; sorry. >> type Object is new Strong_Reference with record >> Ptr : Object_Implementation_Ptr; >> end record; >> >> The implementation of Object's Foo delegates: >> >> procedure Foo (X : in out Object) is >> begin >> X.Ptr.Foo; >> end Foo; >> >> If Object_Implementation must use some existing type, aggregate it. That >> won't change anything, because public clients won't see >> Object_Implementation anyway. Who cares what was the parent type of? > > I can't follow what the code does, sorry. What would be the equivalent of this > C++ code: > > std::shared_ptr shared_object (new Object); > > in the above example? Not even close. The design goals are: 1. Hiding the implementation type from the clients. Clients have no access to the destination object except than through the "pointer". 2. Decoupling "pointer" from the target type. Thus target type can be designed later, there can be more than one target type. 3. Ensuring that each target type implements the interface of the "pointer". The C++'s design is upside down and inside out. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de