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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,591cf01fd1138c66 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!f14g2000cwb.googlegroups.com!not-for-mail From: "Lucretia" Newsgroups: comp.lang.ada Subject: Re: Strange factory for wxAda Date: 18 Oct 2005 09:28:22 -0700 Organization: http://groups.google.com Message-ID: <1129652902.862979.44810@f14g2000cwb.googlegroups.com> References: <1129564741.462159.308620@g47g2000cwa.googlegroups.com> NNTP-Posting-Host: 194.74.199.42 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1129652907 12254 127.0.0.1 (18 Oct 2005 16:28:27 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 18 Oct 2005 16:28:27 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0),gzip(gfe),gzip(gfe) X-HTTP-Via: 1.0 Symantec_Web_Security (3.0.1.74), 1.0 C2100-0050414028 (NetCache NetApp/5.5R5) Complaints-To: groups-abuse@google.com Injection-Info: f14g2000cwb.googlegroups.com; posting-host=194.74.199.42; posting-account=G-J9fgwAAADgpzBiEyy5tO4f8MX5fbpw Xref: g2news1.google.com comp.lang.ada:5773 Date: 2005-10-18T09:28:22-07:00 List-Id: Randy Brukardt wrote: > "Lucretia" wrote in message > news:1129564741.462159.308620@g47g2000cwa.googlegroups.com... > > I'm not sure what I'd recommend in this case. Yup, it's a strange case. One in which I decided the best and easiest way to construct these types by knowing their C++ wxWidgets name is by setting up a factory map (name :-> factory_function). These factory functions then set the C++ pointer and specify that the wxAda object doesn't own the C++ pointer - because it wasn't created there. This may not be the best way to do it, but thus far, I've not thought of any others. > > When the event handler has been called and the event handled, should I: > > > > 1) call Finalize on the pointer explicitly (I've seen CLAW do this)? > > But I didn't realise that you could call Finalize explicitly. > > Certainly, you can -- it's just a procedure, after all. You do need to be Right. I wasn't sure if it had some kind of protection on it like some other languages do, as this is generally called by the runtime and not the programmer. > careful that it can be called multiple times on the same object without > incident, but you ought to do that anyway (it can be called multiple times > in some Abort scenarios, so it's best to protected against that). At the moment, I'm not even thinking about tasking, this will have to be thought about later, when I turn my event handler into some sort of protected object, which will be tricky considering that that is called from C++ :-/ > > 2) call an Unchecked_Deallocation on this pointer? > > If your library is allocating the object, then its OK for your library to > deallocate it. (And that will call Finalize, of course). But you should > never deallocate something that your user(s) allocated. And you may need to > reference count the object (if the pointers can be copied), or better, give > the pointers a limited type (they'll have to be a record in that case, > wrapping the pointer). Well, all objects are derived from a root Limited_Cotnrolled tagged type, if that's what you mean? So, I can copy the access types, but not the instances. Unless you mean create a "smart pointer" type to encapsulate the wxAda *_Type'Access types with? Also, there are "constructor" procedures which handle the "new'ing" of these types, e.g: procedure New_Button(Self : in out Button_Type; Parent : in Window_Type'Class; ...); Inside these a C constructor is called to new the C++ class and return that and in turn store that inside the wxAda type. So the user will never actually "new" an wxAda type because it doesn't make sense to. But, I did knock together a working test of it using Unchecked_Deallocation and after much converting from the "access all Factory_Type'Class" to an Access type it does work, although calling Finalize is probably cleaner as it may not require the conversions. Thanks, Luke.