Strange factory for wxAda

Strange factory for wxAda

[Lucretia]

Hi,

I've another question for you all...

In wxAda it is often necessary to generate an Ada "wrapper" instance
for a particular C++ pointer. An example would be when an event is
triggered from the C++ side that needs to be propogated to the Ada side
so that the correct event handler is called. An event could be wxEvent
or any class derived from it.

These events are of unknown type on the C++ side and so all I can do is
generate a type from a factory on the Ada side using the C++ wx class
name, so "wxEvent" will create an Event_Type, "wxSpinEvent" will create
a Spin_Event_Type, etc. The problem is, when I generate these types, I
new the instance and this instance doesn't get desroyed until the
application exits.

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.

2) call an Unchecked_Deallocation on this pointer?

Has anyone else found themselves in a similar situation?

Thanks,
Luke.

Re: Strange factory for wxAda

[Randy Brukardt]

"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.

...
> 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
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).

> 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).

                  Randy.

Re: Strange factory for wxAda

[Lucretia]

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.

Re: Strange factory for wxAda

[Randy Brukardt]

"Lucretia" <lucretia9@lycos.co.uk> wrote in message
news:1129652902.862979.44810@f14g2000cwb.googlegroups.com...
>
> Randy Brukardt wrote:
> > "Lucretia" <lucretia9@lycos.co.uk> wrote in message
> > news:1129564741.462159.308620@g47g2000cwa.googlegroups.com...
...
> > 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++ :-/

Careful. You really need to think about tasking early on, because it is
extremely hard to graft it on afterwards. Now, you may decide that it simply
isn't worth it, and decide to restrict the uses to one task (as GWindows
does, for instance), but it's best to decide on the approach right away.

> > > 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?

That's what I meant. If you want to do the allocation yourself, you really
don't want any dangling references. So you might want to do whatever it
takes to avoid them (that means making the type limited and not using any
access types in your client interface).

In any case, this seems like a tough problem, which I'm glad I don't need to
solve. :-)

                       Randy.

Re: Strange factory for wxAda

[Lucretia]

> > 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++ :-/
>
> Careful. You really need to think about tasking early on, because it is
> extremely hard to graft it on afterwards. Now, you may decide that it simply
> isn't worth it, and decide to restrict the uses to one task (as GWindows
> does, for instance), but it's best to decide on the approach right away.

Yeah, I know it would be difficult to stick in later, but seeing as
wxAda is in very early stages at the moment, e.g. code rearranging,
getting a very basic app working, etc. to find out what raelly needs to
be done to make a usable library.

Basically, at this moment in time, it would be easy to rearrange the
code I do have to fit it around any major changes.

I also do want to be able to use the tasking features of Ada, this way
I don't need to wrap wxThread, wxMutex, etc. I haven't touched tasking
for a long time (not since university!) so I'd need to get all that
sorted inside my own head (again). I have a question about this, but I
need to think about it some more with the code I have in wxAda for
handling the events from the C++ side to the Ada side, so I'll sort
that out and bring it over later or tomorrow.

> That's what I meant. If you want to do the allocation yourself, you really
> don't want any dangling references. So you might want to do whatever it
> takes to avoid them (that means making the type limited and not using any
> access types in your client interface).

Yeah, I have a smart pointer type in my 3D engine code (I think), I can
nab that ;-D

Currently the wxAda type is derived from Limited_Controlled so yu
cannot copy them, but you can grab the addresses, and after some of
your advice, I changed the code so that the access types are grabbed
inside wxAda. I suppose I could wrap these in my smart pointer type and
store them, that might make sense.

> In any case, this seems like a tough problem, which I'm glad I don't need to
> solve. :-)

Yeah, lucky you! ;-D

Thanks,
Luke.