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,70414f56d810c10c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.66.3 with SMTP id b3mr1131237pbt.3.1316351833957; Sun, 18 Sep 2011 06:17:13 -0700 (PDT) Path: m9ni8933pbd.0!nntp.google.com!news1.google.com!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: discriminant questions Date: Sun, 18 Sep 2011 15:17:14 +0200 Organization: cbb software GmbH Message-ID: <1q85zv3i9ccq6$.17nr90hvonwic$.dlg@40tude.net> References: <9f37b726-d80b-4d24-bf3f-28a14255f7fd@s20g2000yql.googlegroups.com> <86015926-d652-4265-aedd-413312d399f9@dq7g2000vbb.googlegroups.com> <0d272f62-67d0-4905-972c-8a7e912c5531@en1g2000vbb.googlegroups.com> <148cxoyabima2.16mz6xwdph2hj.dlg@40tude.net> <01a1374f-59ab-40be-9e39-0640cb2a513d@n35g2000yqf.googlegroups.com> <1fp2o673mu9az$.d9loz1zbcl0d.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 29fBhZgaWhfH7MiRpNwHjA.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news1.google.com comp.lang.ada:18012 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2011-09-18T15:17:14+02:00 List-Id: On Sun, 18 Sep 2011 05:41:24 -0700 (PDT), ytomino wrote: >> But you can have P.Element which is much more comfortable. There is no >> reason to expose access semantics if you can avoid it. And smart pointers >> are to hide pointers rather than to expose them. > If it hides semantics of access type, > Ada.Containers.Indefinite_Holders gives good interface. One problem of Indefinite_Holders is the definition of "=", it is wrong because Holder is declared tagged. When tagged, "=" must be doubly dispatching. The correct definition should at least be: function "=" (Left : Holder; Right : Holder'Class) return Boolean; -- Emulates double dispatch by cascaded dispatch But this is only an indicator of a bigger problem, which is that the design does not support Element_Type classes. I understand that they didn't want Holder'Class but must allow it to support prefix notation. This is how language design problems get reflected in the container design! Anyway, in my experience smart pointers become almost useless without classes. I.e. you want a hierarchy of elements accompanied by a hierarchy of smart pointers/handles/holders (name it as you wish). You also need *same* set of operations implemented by both, such that operations on the pointer would be delegated to the object. I.e. you don't want: X.Element + Y.Element you want X + Y instead. Even less you want pseudo-functional mess like: X.Update (Invert'Access); you do Invert (X); > (if reference-counted implementation is provided. > but http://gcc.gnu.org/svn/gcc/trunk/gcc/ada/a-coinho.adb is not.) My implementation uses reference counting, because its intended use was to be a smart pointer. The intended use of Indefinite_Holders is not smart pointers. It is only a definite wrapper for an indefinite content, only this nothing more. Smart pointer is also definite, but much more than just that. From smart pointers you expect them being comparable, delegating operations, managing shared objects, supporting serialization, task safety and so on. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de