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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c83a22003c320b45 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-27 11:29:32 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!news.bu.edu!inmet!spock!stt From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: Initialization Params for Controlled Types Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: Date: Thu, 27 Oct 1994 14:27:40 GMT Date: 1994-10-27T14:27:40+00:00 List-Id: In article , Angel Alvarez wrote: >Given that Initialization for Controlled types only takes a single >parameter, the Object to initialize, how can one actually pass >at run-time other data to help initialize the object in one way or >another? ... Passing them as record fields of the object itself? The normal way to "construct" an object in a parameterized way in Ada is with a function. There is no separate notion of "constructor" -- functions are used to do construction. Internally, a function would typically use aggregates and/or allocators to complete the job of construction. E.g.: X : My_Type := Foo(a, b, c); This means that "constructors" in Ada are just normal functions, and their name can give you a clue as to what they are doing (unlike in some other unnamed OO languages ;-). Initialize is really for *default* initialization only, where parameterization (beyond discriminants that control size/shape) is generally unnecessary. The one place where a function doesn't work for parameterized initialization is for an object of a limited type (and even that is not a problem if you generally use access values to refer to such objects). In this case, one way to parameterize the initialization of a limited object is by discriminants. In Ada 9X, discriminants are more general, and can be of an access type. This allows you to "pass in" essentially anything to the (default) initialization (using 'Access if necessary). For a limited object, it is also generally reasonable to call an explicit initialization procedure with any number of parameters. Again, the primary goal of Initialize is to provide *default* initialization. Explicit parameterized initialization can be performed in other ways (via functions or procedures). >It is unclear to me how this could be done for Controlled objects >(by means of default field initialization for the record type itself?) >and at any rate it seems like this solution might introduce "excess baggage" >for the whole life of the object, just to have on hand the data >required at initialization time ... Will anybody please like to comment? See above. It is true that for limited objects, the data used for default initialization needs to be accessible via the discriminants. But again, remember we are talking about default initialization. Explicit parameterized initialization can be accomplished using functions and/or procedures. >Thank you for your help, >Angel Alvarez S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138 P.S. Even if the size of the object being constructed is large, there is no need for a "constructor" concept distinct from functions. Functions are generally just as efficient in decent implementations. In most implementations, if a function returns a large object, the caller passes in the address of a location where to put the result. When used in an initialization context, this location can be the target object itself (since the object doesn't exist yet, there is no harm in using it as the "temp" in which to put the return value). Furthermore, it has become quite common for compilers to implement a "return" optimization where if all return statements return the same local variable, then that "local" variable actually resides in the return "temp" allocated by the caller. The net effect is that the function "constructs" the result directly in its final resting place, and no extra copying (or "adjusting") is performed. -T