Re: [ooc-compiler] gtk-hello-world with oo2c?
Brought to you by:
mva
|
From: Stewart G. <sgr...@us...> - 2008-12-22 08:48:19
|
Hi Frank, I've sent you the code in a private email. It looks like the example includes some callbacks, drawing, etc. To answer your question, it probably depends on what sort of code you're interfacing to. Most pure C APIs can be called directly through an INTERFACE module generated from the original C headers. There are some C language constructs (eg. passing or returning structures by value) that cannot be used from Oberon-2, and if your API uses these, then you need to write some C wrapper functions. I normally put these in a separate module and just use "LINK FILE" in the INTERFACE header to pull in the C wrapper code. If the wrapper includes more than one file, then you have to make a library and include the wrapper using "LINK LIB". To implement a FOREIGN module, you have to generate C language "stubs" by compiling a regular Oberon-2 module that contains the required types. Then you can extend the C structures and add your own C language implementation for the methods of the Oberon objects. You can call any C code you like, providing any definitions you #include are compatible with OOC's own run-time library headers. Normally, objects at the C level have proxy Oberon-2 objects, so it only works well if there are small number of types that you need to implement. OOC uses this to implement operating system interfaces (eg. Files, ProcessManagement, Socket, Termination, etc). The best way to figure out how it works is to study the examples in the standard library. One difficulty with FOREIGN modules is that if you change the types in your interface you may need to regenerate the stubs and merge the old and new code. INTERFACE modules: - preserve methods and types from original API - good for large, complex APIs - exposes C data types to user - requires no coding, except for INTERFACE definition and (possibly) some wrapper functions FOREIGN modules: - hides C data types from user - good for small, simple APIs - implements Oberon-2 objects, which may be proxys for C objects - all methods of objects must be coded in C. Requires some knowledge of OOC's run-time & code generation patterns I hope this helps. Cheers, Stewart Frank Hrebabetzky wrote: > Hi Stewart, > > I surely would appreciate copies of our past discussion as well as some > of your own examples. With an example of the main program, the > implementation an event callback procedure and the placement of a > gadget, I am done. > > I was too short with my question about FOREIGN/INTERFACE. What I wanted > to know is: when would you compile a C wrapper into a library and call > it from an INTERFACE module, and when would you write it as a FOREIGN > module. From what you write, the latter is the better. Otherwise, > FOREIGN module wouldn't make sense anyway, I guess. |