Hi!

Is there a plan to allow the use of C++ libraries with FPC?

Now C libraries can be used and many of them have Pascal mappings. It seems C++ libraries can be used somehow, too. I was looking at qt-library mappings for the Lazarus project. All the classes' methods were mapped into "flat" global functions which had a handle (the self-pointer) as their first parameter. I was hoping to use the classes defined in C++ directly as Object Pascal classes.

This could be a stupid question. There may be big technical obstacles doing it. Like multiply inheritance and C++ templates which should be supported somehow.

My idea was to use a more sane language for programming with the great C++ libraries that exist (like qt). C++ just has so much weight from its history and from the standards committees.
Many people use Python and other dynamic language bindings for those libraries for the same reason. However they carry a big performance and memory penalty which is often too much. A language like Object Pascal (maybe with some extensions) would be a perfect match there.

Where can I find more information related to the FPC libraries? If anyone has other similar ideas, please let me know.

Regards,
Juha Manninen

Hi,

I believe that using C++ objects directly is not very easy. I have found some time ago this site about how to do this in Delphi.

http://rvelthuis.de/articles/articles-cppobjs.html

However, Borland used to publish a C++ compiler at that time. And I believe that this solution is compiler dependant.

Overall, I think that wrapping the object into C function then in Free Pascal is the easy way. If C++ objects are really needed, I prefere to write a C++ procedure to perform everything that really needs this coding, then I wrap it in C and Free Pascal.

I hope I could help more.

Ciao,
Gilles Marcou

In our previous episode, Gilles MARCOU said:

Yes. Random C++ compilers can't use eachothers classes.

Overall, I think that wrapping the object into C function then in Free Pascal is the easy way. If C++ objects are really needed, I prefere to write a C++ procedure to perform everything that really needs this coding, then I wrap it in C and Free Pascal.

Correct, and Rudy above also advises this. It can also be used to hide other problems, like C++ template and other constructs that can't be properly exported to any other compiler. (including other C++ compilers)

About C++ to C, you can see Sun developer's paper: Mixing C and C++ Code in the same program
(http://developers.sun.com/solaris/articles/mixing.html). Very detailed and useful.

2009/10/5 Marco van de Voort :

Hi,

Ok, I understand the situation.
I guess I am looking for a "perfect world" where you could choose your language more freely and still use all the great libraries out there.

I think support for GCC C++ libraries in FPC could be done with enough effort. It would be much more difficult than supporting cdecl or stdcall calling conventions for C libraries of course. Maybe it is not worth the effort.

Interesting things are happening in the interpreted / dynamic language world. For example the Parrot / Perl6 people realized that supporting many languages has no benefit unless they all can use the same libraries as well. And so, all languages run under Parrot really can use libraries written in any of the other supported languages.

http://www.parrot.org/languages

However, dynamic or interpreted languages have resource hungry virtual machines and so they are not suitable for all tasks, and I don't like bloated SW anyways...
I know that Java and such are fast nowadays with JIT compilers but the memory overhead is big and that is not about to change.

So, you want to use a compiled object oriented language, supported in many platforms and having decent libraries. What alternatives do you have? There is C++ and ...
what else... ?
ok, there is Free Pascal!

I have a soft spot for Object Pascal because of my use of Delphi. The language syntax is good now when generics were added. Few more improvements and it would be perfect.

A common library format for compiled OO languages would be a real improvement, competing directly with the development happening in dynamic / interpreted languages.

I guess I am not the first person to have this idea, but... wrote it anyway.

Juha Manninen

---

This is the goal of the Microsoft CLI (Common Language Infrastructure). The library format in this case is an intermediate one rather than a native one (CIL, Common Intermediate Language), but it can be statically compiled into machine code afterwards. It also supports both dynamic languages (there are e.g. IronPython and IronRuby) and non-dynamic languages (C#, F#, C++, C, ...). It's also supposed to have explicit support for mixing different object models in a single program.

Borland/CodeGear tried to take advantage of this with Delphi .NET, but apparently weren't very successful with it (although that's probably in the eye of the beholder). I never looked into the details, so I don't know why.

Having a common API without an intermediate format would however be virtually impossible to design, especially if you want to guarantee backwards binary compatibility for all of the languages that you want to interoperate. You really need some kind of intermediate level with meta-information (higher level than the pure machine code) which describes what is a class, a method, inheritance trees, etc if you want to enable transparently mixing code coming from different languages/compilers.

Well, you could try to write something like http://sourceware.org/libffi/ geared at different object models rather than at simply different ABIs, but I think it would be more fragile and it would offer less integration possibilities.

Jonas

Thanks for your answer.

Now I admit the C++ library support was a bad idea. Even the different C++ compilers are not binary compatible. It is a big mess.

I liked the design of .NET, yes. However, I think compiling CIL to machine code is not the same thing as with real compiled languages. I don't know the details though.
At least my experience is that any program run under .NET or Mono starts slowly and hogs memory. In that respect it is comparable to Java.

So, my "scientific" classification of all object oriented multi-platform programming languages is here:

---------------- ----------------
| Compiled: | | Interpreted: |
| C++ | <---> | All others |
| Object Pascal | | (a long list) |
---------------- ----------------

Note that C is not mentioned because it is not OO. The "All others" list could be still divided into Dynamic and Non-Dynamic but it is irrelevant here. Dynamic language features have still more overhead but when used cleverly they can make the program simpler and smaller.

The main strength of Object Pascal (and FPC) is that it is compiled. I see it as the only justification for the whole language. Otherwise we could just dump it and start using C# or Java or something which have cleaner syntax without carrying historical (pointer) syntax.

This language is not as popular as some others. How to improve it to meet today's demands?
The syntax could still be improved. I understood generics are coming to FPC, too, which is good.

Then, backwards compatibility could be broken. Yes. The old pointer syntax could be forbidden by default and allowed only in some "Error prone mode" or "Ugly code mode".
That would allow more aggressive optimizations in the compiler, too. And yes, I have made big complicated programs with Delphi without using pointer syntax, so it is possible.

Other features could be borrowed shamelessly from other designs and languages. That's how the open source stuff happens anyway. It is not a bad thing.

The main strengths would remain:
Compiled fast and small binary, easy to deploy.
Fast compilation.

Juha Manninen

------------

Juha Manninen wrote

I liked the design of .NET, yes. However, I think compiling CIL to machine code is not the same thing as with real compiled languages.

It can be.

At least my experience is that any program run under .NET or Mono starts slowly and hogs memory. In that respect it is comparable to Java.

You can use .NET in two ways: as a virtual environment similar to Java (in which case you use Mono), or simply as an intermediate bytecode format which is later on compiled to machine code (similar to LLVM -- which you also can use in a virtual environment, for that matter). In the latter case, there is no overhead at all (or there doesn't have to be any, at least).

E.g., STMicroelectronics is using this for their embedded systems using GCC4Net: http://gcc.gnu.org/projects/cli.html . That's both a frontend (compiling GCC-supported languages into CIL -- note that C++ is not yet fully supported at this time) and a backend (compiling CIL into machine code for any CPU supported by GCC).

If that's the only reason why you use Object Pascal, you can probably start using C# instead without any problems.

Jonas

One thing that i did not like about FPC Generics is the impossibility of doing something like this :

Type
  generic TList<_T>=class(TObject)
    type public
       TCompareFunc = function(const Item1, Item2: _T): Integer;
    var public
      data : _T;
    procedure Add(item: _T);
    procedure Sort(compare: TCompareFunc);
  end;
  generic TAdvancedList<_T>=Class(TList<_T>)
   procedure push(item: _T);
   function pop: _T;
  end;
  generic TOtherList<_T>=Class(TList<_T>)
    procedure enqueue(item: _T);
    function dequeue: _T;
  End;

I dont think i explained it very well, the idea was that you cant have generic classes making part of the inheritance tree without specializing then 1st. This makes generics interfere (limiting it) with object oriented polimorphysm... having generics of generics would allow a complete STL capable of being changed (on the fly) into anything needed... (well, i might very well understood generics model wrongly)

one of the solutions i thought was something like this :

Type
  generic TList<_T>=class(TObject)
    type public
       TCompareFunc = function(const Item1, Item2: _T): Integer;
    var public
      data : _T;
    procedure Add(item: _T);
    procedure Sort(compare: TCompareFunc);
  end;
  generic TAdvancedList<_T2> = Class(specialize(TList<_T2>))
     procedure Push(item : _T2);
     function Pop: _T2;
  End;

When the programmer makes :

Type
    TAdvancedListByte = specializeTAdvancedList<Byte>;

the compiler would automagically generate an intermediate TListByte that specializes TList<_T> (Replacing _T with _T2) and replace the original Class(specialize(TList<_T2>)) with Class(TListByte), all of this on the fly, making intermediate classes to be part of the inheritance tree, and allowing a big generics library possible...

thats my two cents...