In this work I have developed a software which try to facilitate the condivision of software libraries between different programming languages.

Brief summary about proposed solution for integration

I have explained that my approach to get these two systems cooperating is based on local cooperation: this fact mainly means that I don't use any network infrastructure (such as a network interface at hardware level and a communication protocol at software level) but I use only (and this is, I hope, the real innovation I would like to focus attention) local memory condivision and data structures conversion by a middle-layer component called Foreign Function Interface.

No more clients and servers are needed to get best properties from every single language, as we normally do using CORBA and DCOM, the leader on the market of network-based software integration: I propose in fact an architecture in which client and server are in execution inside the same process. This led to a simpler program to start up, to debug etc.

In the specific of the application CScheme (which binary files and source code are freely available in the "Download" HTML page) these two languages are Scheme and C++; the former give us an interpreted environment where a developer could execute simple commands or complex script; the latter is a the languages on which Open Cascade rely to describe its geometric (and not only geometric) services.

Problems still unresolved

It is necessary to remark that CScheme application is actually only a prototype and, being a prototype, it could be used to develop simple 2 or 3 dimensional models or to familiarize with concept just exposed; but probably It can be hardly used in any industrial contest.

The most important problems which are still unresolved are the following:

[Memory deallocation] There are some problems of cooperation between the Garbage Collector of MzScheme (a conservative pointer GC) and the Reference Counter mechanism adopted through Handle in Open Cascade. Actually all memory realeases are disabled .

[Benchmark] CScheme prototype is very slow. First of all the instructions executed by the FFI are very complex; it checks if there are any match between actual parameters and formal parameters and it supports "User conversions" by which an argument could be matched by the execution a one-argument constructor or a conversion operator. I think that bad benchmarks are also connected with a programming choice that seemed to me the best at first: I have implemented the FFI interface using CDL language. For example I have defined the CVar structure by CDL language and I generated (by CPPExtractor and SchemeExtractor) corresponding header class files. It is probably a very elegant solution (a FFI which grows on Ocas) but it leds to poor performance.

[CDL parsing] Every time CScheme application starts, there is the need to parse CDL files to recreate Metaschema informations (a Metaschema is a container of classes, methods, aliases, enumerations, packages etc.). Scheme interpreter and FFI methods rely on this kind of informations to perform argument conversions and to find the method which best matches actual parameters. Therefore some waiting-time is needed to perform this task at every start-up.

[Glue code dimension] The matching operation between actual parameters to formal parameters is performed at run-time; on the contrary the link to the function itself is static. The FFI generates the number of the function to call basing on its conversion algorithms and then it calls the "Upper Caller" method which is a sort of container of calls to library methods.This fact led to big "Upper Caller" files (about 1 megabyte for not trivial packages such as BRep_XXX) and this slows even more application benchmarks. The alternative choice is to link library methods in a dynamic mode.

[More packages] Actually only few packages are integrated into CScheme. The extension to other packages could be done quickly, but it will led to the generation of a bigger CScheme executable.