I am a little confused about this issue. Unless we are compiling and linking to the C++ source code, why it is necessary to support C++? Couldn't the QT header files just be converted to Pascal the same way the GTK header files were? Once the code is compiled, it just makes calls to the binary objects at the binary level, right? Or not? And Pascal already supports most of the same things as C++ except multiple inheritance and maybe a couple of others. So I would think that the header files could be converted without too much trouble. There might be a few challenges to work through (like multiple inheritance), but I would think it wouldn't be all that hard.

Unless I am wrong about how all this stuff works at a lower level, I don't see any reason that the compiler should need to support C++. Can someone explain to me what I am missing here?

How hard would it be to add that support to the compiler if it is needed?

Curtis

A lot, the low level stuff works completly different:
- Qt uses C++ classes but the FPC class modell isn't compatible with that one used by egcs (and that one used by egcs isn't compatible with that of gcc :()
- MI requires a lot of changes (syntactical and semantical)
- C++ uses a complete different exception handling model

How hard would it be to add that support to the compiler if it is needed?

It IS hard but I'am working on it :)

Using shared libs.

I was wondering this myself. I still don't see how they are going to provide support for Open Source without releasing the VCL source code as Open Source. How could a person possibly build an Open Source application based on the VCL without the VCL being Open Source? I'm a little curious to see how they will manage that...

Curtis

Curtis White wrote

Florian Klaempfl wrote: So if I compile a .so file with gcc and then I compile a .so file with FPC, do those two .so files work differently internally? This is really confusing to

Well, this is called ABI: Application Binary Interface.

The basic stuff is defined by Intel (which made some errors, like aligning doubles at every 4th byte, instead of 8th byte, which slows double using programs on anything after a Pentium), but the higher level conventions come from the compiler.

C++ needs much more infrastructure then C, so there are a number of conventions built into the compilers. On Windows it's a well known thing that all parts (DLLs) must come from the same C++ compiler. On Linux this has been less of a problem, because almost all compilers are derived from gcc/egcs backend, and as such use the gcc/egcs conventions. FPC OTOH, is a standalone compiler.

Well, it's a number of thing: Calling conventions, Name Mangling, error and exception handling, and struct(RECORD) layout stuff.

What about on Windows? Is an .exe or .dll file that is compiled with FPC different than an .exe or .dll file compiled with Borland C++ Builder or MS Visual C++ or Delphi?

Jep, it is.

Andreas

Kylix GUI Components to be Built Upon Popular Qt Crossplatform Linux Framework
http://biz.yahoo.com/prnews/000427/ca_troll_t_1.html

So if I compile a .so file with gcc and then I compile a .so file with FPC, do those two .so files work differently internally? This is really confusing to me because I had thought an executable was the same no matter which compiler it was compiled with. I always thought the compiler just took the source code and made it into assembly and then the linker turned it into binary code. I didn't know that the binary code was different depending on which compiler you use. That is interesting.

What about on Windows? Is an .exe or .dll file that is compiled with FPC different than an .exe or .dll file compiled with Borland C++ Builder or MS Visual C++ or Delphi?

Great! Is it planned for version 1.0 or later?

Curtis

Yea you can build a open source app on it but you cannot distribute the VCL which is the model they will most likely take.

Cliff

Correct me if I'm wrong but I think using .so is similar to using .dll Both are binary libraries. I think a .so / .dll generated by fpc dousnt differ from one genrated by an other app.
Point here is the way these libs are called. If the lib contains flat functions you have a calling convention on how the parameters are passed. To call gtk libs, we use the cdecl convention. If you want to use functions from a dll you use the stdcall convention.
For objects being passed between libs, you need more than a calling convention, you also need to support the same objectmodel. IE, how are methods called and how do I look them up in the VMT. On the project I'm currently working on I use Interfaces to interface between the delphi objectrs and say for instance VC objects.

Marc

A lot, the low level stuff works completly different:
- Qt uses C++ classes but the FPC class modell isn't compatible with that one used by egcs (and that one used by egcs isn't compatible with that of gcc :()
- MI requires a lot of changes (syntactical and semantical)
- C++ uses a complete different exception handling model

How hard would it be to add that support to the compiler if it is needed?

It IS hard but I'am working on it :)

Cliff" wrote

Linux PR just picked up on the Lazarus Story www.linuxpr.com

Now let's see if any of the other services pick it up from that.

Probably used my code ;) He He

Cliff

Curtis White wrote

Kylix GUI Components to be Built Upon Popular Qt Crossplatform Linux Framework http://biz.yahoo.com/prnews/000427/ca_troll_t_1.html

This is known stuff; only know they have a paper to prove it :-)

We should try and get the C++ support working in the compiler, so we can interface to native Qt libs, not using a wrapper...

Michael.

Curtis White wrote

Kylix GUI Components to be Built Upon Popular Qt Crossplatform Linux Framework http://biz.yahoo.com/prnews/000427/ca_troll_t_1.html

Interesting. Cliff is already there. Since it talks about licenses.

"As a result of the agreement, Inprise/Borland can leverage Qt in its forthcoming Delphi(TM) and C/C++ rapid application development (RAD) environment for Linux code named Kylix(TM). Financial terms of the deal were not disclosed."

Does this mean that since money changed hands that it might not be open source?????

Not with the native name space mangling and such.

Cliff

Linux PR just picked up on the Lazarus Story

www.linuxpr.com

Cliff

Yep, that's the point.