I'm trying to understand something. Best explained through an example.

My understanding is that a Class Adapter (lets say written in C++) is for a class written in PHP (hypothetical).
C++ - Class A - Adapter
PHP - Class B - Adabtee.

If I'm trying to access Class B through class A written in another programming language then how do they communicate. The reason I ask is because they are written in different programming languages so how can the Adapter communicate with an Adaptee? Furthermore... How does one compile an Adapter (in a program) when it has to access the Adaptee written in another programming language? Are they compiled separately then linked?

Thanks
Danny2000

Are they compiled separately then linked?

Yes.

The linking may be done either statically or at load/run time from a .dll or .so

Thanks.

Are you able to clarrify how this occurs.

If I'm trying to access Class B through class A written in another programming language then how do they communicate. The reason I ask is because they are written in different programming languages so how can the Adapter communicate with an Adaptee?

If I'm trying to access Class B through class A written in another programming language then how do they communicate. The reason I ask is because they are written in different programming languages so how can the Adapter communicate with an Adaptee?

Any clues to the original question. Conceptually it seems impossible????

I don't have any idea about this topic, but I googled and found this. Hope its relevant.
And thanks for asking this question, I didn't knew that two different languages could be linked :)

Edited 4 Years Ago by np complete

Most programming languages and some scripting/interpreted languages have the capability of calling C functions in a DLL or .so file (i.e., a shared library). This is what usually serves as the glue between any two language, and is most often the basis for other frameworks geared towards inter-language interfaces (like COM objects in Windows). If you do this by hand (without the help of a special tool or library), the process is usually as follows:

  1. Write your code in Language 1.
  2. Write a set of C-compatible function (i.e., with a standard calling convention, no name-mangling, only opaque pointers or primitive types as parameters, etc.) in Language 1.
  3. Compile (or encapsulate) the code from steps 1 and 2 into a shared library (or DLL) which exports all the C functions.
  4. Write code in Language 2 that wraps the C function calls into a structure (classes, and functions) that mirror the original code (step 1), but in Language 2.
  5. Link (dynamically) all your Language 2 code with the shared library created in step 3.

For simple applications, the above can be done by hand very easily. For larger applications, it might be very difficult to do it just based on the two languages that you are dealing with (especially being able to do step 4 with fidelity). And, you would normally use an automated tool for this purpose. These tools vary between language combinations, and some consist only of libraries in the destination and/or source language, while some are more involved tools that include some parsing and code generation before you can compile. One example of a library-only tool is Boost.Python, which interfaces C++ code with Python code, both ways, and it mostly works off the fact that Python has very easy means to interface with C libraries and has a COM-like interface specification. One important example for a more elaborate tool is SWIG, which can do a lot of cross-language stuff (including things like calling a script from a C/C++ code which requires the interpreter to be launched to execute the script).

So, you see, the above steps are just the general process, but it can vary highly between languages, operating systems, and compiler suites. Some compiler suites (like ICC, GCC, MS compilers, etc.) can glue certain kinds of codes together automatically, often because they use a similar binary interface in all their compiled code. Some operating systems (mostly Linux / Unix) have standard binary interfaces and a tighter integration between shared modules and executables, which usually simplifies the process as well. So, overall, it is very much a case-by-case basis, but for a small project, the steps outlined above are a pretty safe bet.

Brillian.. Thanks very much for those answers. I think that explains it well.
Cheers.
danny2000

This question has already been answered. Start a new discussion instead.