> You also get breaking backwards compatibility with a lot of existing
Delphi code for free. I repeat: you really cannot underestimate the
amount of<br>> implementation details that existing Delphi code depends on,
and people already complain about FPC's incompatibility with those
implementation details.<br>Just so we are clear, what implementation details are you talking about (that you would loose with C++ ABI)? C++ Builder and Delphi have the same ABI and they work quite nicely together. There are even C++ libraries being used inside delphi (like xerces and xalan). Even Delphi VCL is used inside C++ (Builder). Btw how does the wxForms for Delphi (port of wxWidgets) on Delphi work? It is commercial so I don't know how they have resolved the C++ linking problems because they also claim FPC compatibility. Another possible option is to create a Objective C LLVM wrapper, since FPC already claims to support it.<br>
<br>> So what is holding you back? Really, trying to convince other people to
do something that you would like to see done (or even worse: to work on
it in the <br>> way that you would prefer them to do it) in general just
doesn't work. The only way to achieve your projects is to start working
on them yourself, and hope<br>> that other people join in.<br>Currently I am still working into getting more complete COM support into FPC (0014919) and a lot is already in SVN. What is holding me back is crashing of applications using FPC DLLs (0014861 and 0014807). I could help LLVM efforts, but couldn't really lead a LLVM port, due to lack of time. But nevertheless debating how each developer see the benefits of each solution is still good IMHO (no matter what direction the development will actually take). Maybe i'll start next on more complete support for C++. Because I need xerces/xalan and it uses only virtual functions inside C++ (so it should be simple to port). Or just create OO for libxml/libxslt or start effort to implement native FPC xslt.<br>
<br>> No, the question is what do people submit patches for.<br>
True, but more readable code helps :) I tried to resolve above bugs myself by studying FPC compiler a bit, even working on cleaner FPCDoc parser (0011240), but fpc compiler is just too complex and confusing (for the available time that I currently have :) ).<br>
<br>> I have no idea. All I know that's slightly related is the alioth
computer language benchmark game (with the stress on "game"), where you
have at least both<br>> FPC and GCC results.<br>Yup, the FPC factor is 2x-10x slower. <a href="http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=fpascal&lang2=gpp&box=1">http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=fpascal&lang2=gpp&box=1</a><br>
LLVM that is currently 30% slower than GCC and could speed FPC quite a bit :).<br><br>
Matej Spiller-Muys<br><br>