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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a3f460aaba1863e2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 28 Jul 2005 19:37:52 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1120752411.808598.292980@g49g2000cwa.googlegroups.com> <1121269243.013754.57720@g14g2000cwa.googlegroups.com> <1121883276.400592.326630@o13g2000cwo.googlegroups.com> <1122315253.757948.150350@z14g2000cwz.googlegroups.com> <8_ydncLVTeRn5njfRVn-jA@megapath.net> <1122485760.918191.274380@f14g2000cwb.googlegroups.com> <1122545378.984920.272260@g47g2000cwa.googlegroups.com> Subject: Re: Private primitive operations available to entire package hierarchy. Can it be done? Date: Thu, 28 Jul 2005 19:40:58 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4952.2800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4952.2800 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-MQTJOMIaMUBu+7/fVazLcJfYG/hwoL7prtYMqmbH39huPLavYCG17Qdv0ZYpz1T60xxYUIhzwN7Ok3N!SOYYJ6mITo/b6mlewDyKqGXM8Eg/mnAJKa8UZQR161VoOxOUki2DtdwB1pWsQ/Qtz/xB+bfi6u/h X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:3827 Date: 2005-07-28T19:40:58-05:00 List-Id: "Lucretia" wrote in message news:1122545378.984920.272260@g47g2000cwa.googlegroups.com... ... >>> and having all primitives take an access parameter as the controlling >>> parameter. >>That's awful. If you do that, you're requiring your user to do memory management >>for you, rather than the other way around. They'll be forced into subpar syntax >>(explicit uses of aliased and 'Access), have runtime accessibility errors, and >>other nastyness. And they would have no way to use the containers library >>do the storage management for them. >What's awful? Using access parameters as the controlling type or just >using instances the way I have been doing? Using access types in the user interface. I believe that they should be limited to cases where there is no other choice (generally because of copying issues). > I don't really see what you mean about forcing the user into handling > the memory management. subpar syntax? Dunno what that means :-/ If you use access types in the parameters, then the users of your interface will have to either: * use an allocator (new) to create objects. In that case, they'll have to use Unchecked_Deallocation to get rid of them. That puts a lot of effort on the user that they may not need the power of (often stack allocation is just fine for objects); or * declare objects with the ugly "aliased" syntax, and worse, have to use the 'Unchecked_Access attribute in most calls. Which means a lot of extra typing (and more importantly, reading) that has nothing to do with their program. Moreover, if you use access types in this way, you're preventing the users from using an Ada.Containers container to do their memory management. They'd have to put access values into the container, and do their own memory management on those values -- pretty much defeating the purpose of a container. There is also the issue of accessibility; you can get runtime failures if user pass 'Access of a local object and you want to store that into some library-level type (even for immediate, short-term use). In Ada 95, you can't pass null, either, so even that tiny utility is not available. My motto is to let the user of my libraries to determine the memory management most appropriate for their uses, and that means passing objects, not access values. Given Ada's rules, the generated code is the same either way anyway - indeed, object passing is likely to be cheaper (no accessibility level to pass). Just say no to anonymous access parameters. :-) [Personally, I believe that anonymous access types were a complete mistake; the only issue was missing "in out" parameters for functions. There is no technical advantage to using anonymous access types in any situation, and many pitfalls.] And the implementation of Add: procedure Add (Sizer : Sizer_Type; Button : Button_Type'Class) is My_Button : Any_Button_Access_Type := Button'Unchecked_Access; My_Sizer : Any_Sizer_Access_Type := Sizer'Unchecked_Access; begin -- Call the low level (C) routines: wx_Add (My_Sizer, My_Button); -- etc. end Add; You might need to do some type conversions on the access types, but that's > I thought that it was considered bad to get the access of a parameter > in this way? I sure hope not, its the central tenet of the Claw design. It *is* necessary to be careful about lifetime issues. There is nothing to worry about if the access value will not be used any longer than the duration of the call - the parameter cannot be finalized while the call is active (unless the program is erroneous anyway - it would probably crash for reasons having nothing to do with your library if that happened). If you need to use it longer, then you have to make sure that you have a way to destroy the access value if the object gets finalized while you are still holding onto the access value. Claw uses controlled types for this; when an object is finalized, the object is removed from all lists and other objects that it is in (obviously, that means making sure that the object keeps track of every place that it is linked). Note that these issues are exactly the same if you use access types. The only difference is that you might get a runtime failure if the user used 'Access instead of 'Unchecked_Access. (By doing this in your own code, you can avoid having to require your users to use 'Unchecked_Access for their calls to work reliably.) Randy.