Thanks for all your messages.
Basically I need to have at least a (void *) pointer to an idst object
in the C++ side in order to dispatch polymorphic method calls. On the
idst side I will also need a pointer to a C++ object so that each side
can communicate using low level C functions.
I take care of the lower level C binding to FLTK. I don't use a C++
PEG but an analytical grammar with the language machine
(http://languagemachine.sourceforge.net/) that ignores the body of the
C++ function and does not understand templates.
Below is what I can generate so far. There is no oop pointer yet in
the generated Wrapped_SomeCppClass class since I was not sure how to
deal with it. The C function named
"Dispatch_SomeCppClass_aPolymorphicMethod_5" is the the one in which I
will have to send an idst message in C (like this example {
_sendv(s_println, 1, (oop)(7 * 6) << 1 | 1)); }).
Thanks to your hints I should get one step closer to completion.
[EMAIL PROTECTED]:~/pepsi/wrap$ lm -r wrapper
// input code.
struct SomeCppClass
{
int anAttribute ;
void aNonPolymorphicMethod ();
virtual int aPolymorphicMethod ( char ** withAnArgument );
SomeCppClass () { // a constructor }
};
// Binding code generation will begin below:
struct Wrapped_SomeCppClass : public SomeCppClass
{
virtual int aPolymorphicMethod ( char ** withAnArgument ) ;
Wrapped_SomeCppClass ( ) ;
};
// Imported function declarations.
extern "C"
{
// dispatch - From struct SomeCppClass.
int Dispatch_SomeCppClass_aPolymorphicMethod_5 ( void * self,
char ** withAnArgument ) ;
} // End of imported functions.
// definitions - From struct SomeCppClass.
int Wrapped_SomeCppClass::aPolymorphicMethod ( char ** withAnArgument )
{
return Dispatch_SomeCppClass_aPolymorphicMethod_5 ( this, withAnArgument );
}
Wrapped_SomeCppClass::Wrapped_SomeCppClass ( )
: SomeCppClass ( )
{ }
// Exported methods declarations.
extern "C"
{
// extern - From struct SomeCppClass.
void Wrapped_SomeCppClass_aNonPolymorphicMethod_4 ( void * self )
{
(( Wrapped_SomeCppClass *) self
)->SomeCppClass::aNonPolymorphicMethod ( );
}
int Wrapped_SomeCppClass_aPolymorphicMethod_5 ( void * self, char
** withAnArgument )
{
return (( Wrapped_SomeCppClass *) self
)->SomeCppClass::aPolymorphicMethod ( withAnArgument );
}
void * Wrapped_SomeCppClass_new_6 ( )
{
return ( void *)( new Wrapped_SomeCppClass ( ));
}
} // End of exported functions.
On Tue, Jun 24, 2008 at 3:54 AM, Kurt Stephens <[EMAIL PROTECTED]> wrote:
> A solution might be to modify C++ new/delete operators to allocate extra space
> to store an extra word for the idst oop ptr peer, which is the technique that
> libid uses internally. But that wont help with static allocations. :(
>
> Or use an invertible map between C++ this ptr and the oop peer. But that
> probably wont play nice with GC.
>
> Regardless you will need to resolve idst message selectors on the C++ side
> at init time. Maybe its time for a C++ PEG? I shudder at the thought.
>
> Is there a lower-level C binding to FLTK?
>
> Kurt
>
> Rémy Mouëza wrote:
>> Hello,
>>
>> I am stuck in front of a problem: I would like to send messages to a
>> idst objects from a regular C function. However, after a look at the
>> compiler, the libid.c file and the generated code I don't have any
>> clue to make it simple and straightforward. Actually I feel lost.
>>
>> My final goal is to call that later function from C++: I am currently
>> writting a binding generator to be able to use the FLTK library from
>> idst. I am using the principles used in Qt for Ada which can be found
>> here: http://qt4ada.sourceforge.net/index.php?current=ada_cpp : I
>> derive C++ classes to be wrapped and bound then I shoul have the
>> derived class dispatch their virtual method to idst object (stored as
>> void * pointers on the C++ side) which would then either redefine the
>> method behaviours or simply call the C++ super method.
>>
>> Has anyone any guidelines or hints about doing this?
>>
>>
>> Rémy.
>>
>> _______________________________________________
>> fonc mailing list
>> [email protected]
>> http://vpri.org/mailman/listinfo/fonc
>
>
> _______________________________________________
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
