comp.lang.ada
 help / color / mirror / Atom feed
From: "Lucretia" <lucretia9@lycos.co.uk>
Subject: Re: Strange factory for wxAda
Date: 18 Oct 2005 09:28:22 -0700
Date: 2005-10-18T09:28:22-07:00	[thread overview]
Message-ID: <1129652902.862979.44810@f14g2000cwb.googlegroups.com> (raw)
In-Reply-To: zoSdnVCl7e8q38neRVn-qQ@megapath.net


Randy Brukardt wrote:
> "Lucretia" <lucretia9@lycos.co.uk> 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.




  reply	other threads:[~2005-10-18 16:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-17 15:59 Strange factory for wxAda Lucretia
2005-10-18  0:36 ` Randy Brukardt
2005-10-18 16:28   ` Lucretia [this message]
2005-10-18 21:53     ` Randy Brukardt
2005-10-24 13:09       ` Lucretia
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox