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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,2f84446733b06aca X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,27502d015551c708 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,2f84446733b06aca X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Constructors for Ada (was: Converting C++ class to Ada) Date: 1996/12/17 Message-ID: #1/1 X-Deja-AN: 204548216 references: <32ADF183.7195@lmtas.lmco.com> <58npck$iku$1@goanna.cs.rmit.edu.au> organization: The Mitre Corp., Bedford, MA. newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.eiffel Date: 1996-12-17T00:00:00+00:00 List-Id: In article mheaney@ni.net (Matthew Heaney) writes: > Then we have a philosophical difference. I would like to allow the > user to have more control of the initial state of a limited object, > by invoking the constructor of his choice. And to be able to do it > in the declarative region. Let's see. In Ada 83 the concept of limited types was introduced to allow treatment of task objects to be consistant with that of other objects. As a result you can have objects with tasks as components, etc. But the characteristic of limited types is that they don't have an assignment operation. (By default limited types don't have "=" either, but an "=" function can be added, as can a ">", etc.) Having said that, Ada 95 went through several gyrations about functions returning limited types. The final result is at 6.5(11..21) and defines "return-by-reference" types. The net effect of all this is that you can have a function returning a limited type, take 'ACCESS of the call and assign it to an access value: type File_Access is access Text_IO.File_Type; function Open(Name: in String; Mode: in Text_IO.File_Mode := Text_IO.In_File; Form: in String := "") return Text_IO.File_Type; ... A_File: File_Access := Open("My_File")'Access; ... Text_IO.Close(A_File.all); If you think it is cleaner you can even define Open to return a value of type File_Access, but I don't recommend it. RM 3.10.2(10) has another bit of magic about functions which have return-by-reference return values. The static nesting depth of the return value is that of the scope containing the body of the function. This allows you to avoid accessability checks and not be required to manage the garbage collection. (In most implementations, the used file objects will be reclaimed when you exit the scope where the open function was declared, so there are cases where you do want to nest it.) (Of course you can be clever and define two functions, one of which calls the other, and either hope that the comiler figures out that the accessability check can be made statically, or use inlining to provide a clue.) > The syntax rules prevent one from initializing a limited object in > the declarative region (because no assignment is available). Why > should initialization of limited objects have to be done > differently? Because no assignment is availiable? Remember that there are going to be limited objects for which assignment is not available anywhere, such as objects containing tasks or protected objects. But notice that you are not prevented from initializing limited objects in a declarative region, you are only prevented from doing it by assignment. That is a prohibition that is not specific to declarative parts. Of course it is REAL ugly to initialize an object as the side effect of a later declaration, but it is not prohibited. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...