Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Stewart G. <sgr...@ii...>]

Hi Frank,

>> I'm interested in being able to use existing C++ APIs from Oberon-2.
> 
> It would certainly broaden the options available. There are some C++ 
> APIs I have an interest in.

Did you have anything special in mind? I'm particularly interested in 
GUI/application toolkits. There are lots of these around for C++ (eg. 
wxWidgets, FLTK, Qt, JUCE), but only relatively few for C.

>> Currently, oo2c has a limited ability to call methods of C++ objects. 
>> When one declares a record with the VTABLE flag, oo2c builds a 
>> C++-style virtual method table for all instantiated objects, and calls 
>> methods of that object via VTABLE dispatch. This means (for example) 
>> that you can call methods of COM interfaces, and even implement your 
>> own COM objects.
>>
>> This is fine if one follows a design methodology like COM, which 
>> ensures that there is a language-independent binary interface to your 
>> API. COM uses abstract interfaces and VTABLE method dispatch. It also 
>> has a language-independent type mechanism (ie. 
>> IUnknown::QueryInterface). Unfortunately, most C++ coders seem 
>> completely uninterested in language interoperability. The biggest 
>> obstacle with existing C++ APIs is the use of static (ie. non-virtual) 
>> methods. Its only really possible to call these methods from a C++ 
>> compiler, since the symbol names are mangled to include type information.
>>
>> The approach that I'm proposing is to:
>>
>> 1) Introduce a [STATIC] method flag. This causes calls to methods to 
>> be dispatched statically, rather than using type-descriptor lookup.
>>
>> 2) Write (by hand, or automatically) a FOREIGN implementation that can 
>> be processed by the C++ compiler. This dispatches method calls to the 
>> C++ objects.
> 
> 
> Would it not be simpler to have OOC mangle the symbol names the same way 
> as the C++ compiler? I realise that is compiler-dependant and I believe 
> g++ broke ABI recently by changing the mangling algorithm. Even so the 
> algorithms should be reasonably easy to discover (especially for g++). 
> There would remain the issue of telling OOC which algorithm to use.

I suppose that might work. Within the current oo2c implementation it 
would need to be possible to access the mangled symbols from C code. I'm 
not sure if that's possible - presumably the compiler writers take steps 
to prevent the mangled names colliding with the mangled symbols. 
Certainly, it would be possible at the asm/linker level.

There's another advantage of the wrapper approach, which is that one 
does not need to know about the calling conventions of the wrapped 
function in order to call it from client modules. At least under 
Windows, there are different calling conventions possible (eg. stdcall, 
cdecl, fastcall). It should even work for macros and functions that 
would normally be "inlined".

There are a few other issues that I think could also be addressed within 
the same wrapper framework. One problem that I've hit before is that 
many APIs (even "C" APIs) pass small records by value. For example, GSL 
does this for complex numbers, and OpenCV does it for image dimensions. 
In the past I've solved this by manually writing a wrapper function that 
accepts a record by reference, and then dereferences the pointer in the 
function call. It would be nice to get an easier solution to this 
problem too.

Cheers,
   Stewart