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.58.168 with SMTP id s8mr1003329pbq.15.1316335813263; Sun, 18 Sep 2011 01:50:13 -0700 (PDT) Path: m9ni8809pbd.0!nntp.google.com!news1.google.com!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 10:50:12 +0200 Organization: cbb software GmbH Message-ID: <148cxoyabima2.16mz6xwdph2hj.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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 7z0UX2w5VvdwUzbN9OGJuw.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:18008 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2011-09-18T10:50:12+02:00 List-Id: On Sat, 17 Sep 2011 15:55:15 -0700 (PDT), ytomino wrote: >>C++ does not have implicit dereferencing at all. Ada has it but only for >> attributes, array indexing, component members. > > C++ has it. > > struct reference_type { > int *element; > operator int & () { return *element; } > }; Dereferencing is implicit when a pointer is substitutable in the context where the target type is expected. Though C++ supports user-defined type conversions, it does not do it for pointers. > This code is same as: > > type Reference_Type (Element : access Integer) is null record; It is not same, and I don't see the purpose of using this construct. In any case it cannot serve as a good basis for smart pointers. > Therefore, there is no reason that we could not it with Ada. > ...except assignment. You can write it, but again, what are you trying to achieve? > Two Ada variables having different discriminant are incompatible > and it raise Constraint_Error at runtime. > But if default value exists, we can assign these variables. It is not so. Discriminant is an integral part of a value, which can be changed only together, as a whole. Another issue is that an object can be constrained to a class of values having certain values of the discriminants. > So I can not make smart pointer like syntax of raw access types after > all. If you mean specifically overriding the "operation" X.all, no you cannot. But I see no reason for that in the context of smart pointers, where you wanted to get rid of pointer semantics, rather than mimic it. The latter is possible to do in Ada, but admittedly boring. I did it some projects. The schema is as in the example I gave earlier, plus interfaces on top of it: type Foo_Interface is limited interface; procedure Bar (X : in out Foo_Interface) is abstract; type Foo_Object is new Object.Entity and Foo_Interface with record ...; overriding procedure Bar (X : in out Foo_Object); type Foo_Object_Ptr is access Foo_Object'Class; package Foo_Handles is new Object.Handle (Foo_Object, Foo_Object_Ptr); type Foo_Handle is new Foo_Handles.Handle and Foo_Interface with null record; overriding procedure Bar (X : in out Foo_Handle); procedure Bar (X : in out Foo_Handle) is begin X.Ptr.Bar; -- Delegation end Bar; Now the object (Foo_Object) and its smart pointer (Foo_Handle) can be used interchangeably in the context where Foo_Interface is expected. Normally you would hide the objects and expose only handles to them and factories returning handles to newly created objects. > I want to know the reason. Discriminants of anonymous access types were meant to be safe (though, they are not). That was the reason for a pile of (incomprehensible) rules limiting use of such discriminants. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de