Jason P Sage wrote:
Hello All,
This may have been mentioned with different words already - but I'm getting
the impression one should write a "C++ handler API" or "thin layer" for the
C++ lib one wants to utilize. The idea being FPC would only link on standard
calls that more or less ran the unde
While playing around with the compiler source to familiarize myself I've
produced the attached patch. While I didn't set out to produce anything for
inclusion into the official codebase at least some of the changes might be
generally useful.
a) now modeswitch: m_ident_escape
Allows escaping of id
Hello All,
This may have been mentioned with different words already - but I'm getting
the impression one should write a "C++ handler API" or "thin layer" for the
C++ lib one wants to utilize. The idea being FPC would only link on standard
calls that more or less ran the underlying C++ lib like a
About the name mangling: this thing is compiler specific. To have really
portable code, whoever compiled the DLL should include flattened
procedural API model without name mangling. See the Kylix QT libraries:
borland have compiled their own version of Qt2.3.0 and have exported
things in a
Op Mon, 22 Jan 2007, schreef Felipe Monteiro de Carvalho:
> Maybe the compiler could hide the
> procedurization/re-object-orientation, thus making interfacing easier.
Already looked at many times, but it is not realistic.
Daniël___
fpc-devel maillist
On 1/22/07, Jonas Maebe <[EMAIL PROTECTED]> wrote:
No, just with "cppdecl" instead of "cdecl". Afaik we even already
have that keyword in the compiler. It just doesn't do any C++ name
mangling currently.
Can´t name mangling be utilized on other calling conventions besides cdecl?
--
Felipe Mont
On 1/22/07, Felipe Monteiro de Carvalho
<[EMAIL PROTECTED]> wrote:
And using proceduralization / re-object-orientation manually would
result on something even much larger, perhaps 2 times larger or more.
Just to avoid mis-interpretation. It´s not only a question of saving
lines of code, but als
On 1/22/07, Felipe Monteiro de Carvalho
<[EMAIL PROTECTED]> wrote:
Maybe the compiler could hide the
procedurization/re-object-orientation, thus making interfacing easier.
Basically this would be nice for me because the Symbian OS headers are
incredibly huge. There more then 100.000 lines of .h
Maybe the compiler could hide the
procedurization/re-object-orientation, thus making interfacing easier.
So this:
type
User = class
public
function Sum(a, b: cint): cint; cdecl; external 'cpplib.dll';
end;
Would be the exact equivalent of:
function User_Sum(Self: Pointer; a, b: cint): cint;
On Monday 22 January 2007 21:14, Peter Popov wrote:
> example is the way QT is interfaced with Kylix. It works, only because QT
> is reasonably well written, all the new/deletes of QT objects are
> explicitly wrapped in Kylix, and the published QT member functions don't
> do weird things. All
Op Mon, 22 Jan 2007, schreef Felipe Monteiro de Carvalho:
> On 1/22/07, Daniël Mantione <[EMAIL PROTECTED]> wrote:
> > Of course, you can import a class like you did, and even automate it, I
> > don't see a problem with adding C++ mangling. But, you cannot use class
> > syntax, since classes are
On Monday 22 January 2007 20:17, Felipe Monteiro de Carvalho wrote:
> Hello,
>
> Now, I utilized dllview software I created and saw that cpplib exports
> this function: _ZN4User3SumEii
>
IIRC C++ compiler/platform dependant.
So do not use this to be compiler independant
GCC even changed its name ma
On 22 Jan 2007, at 21:45, Felipe Monteiro de Carvalho wrote:
function User.Sum(Self: Pointer; a, b: cint): cint; cdecl; external
'cpplib.dll'; cpp_method_name_mandling;
No, just with "cppdecl" instead of "cdecl". Afaik we even already
have that keyword in the compiler. It just doesn't do an
On 1/22/07, Peter Popov <[EMAIL PROTECTED]> wrote:
Take a specific look at the second part, with pure virtual classes. The
trouble is it only works for virtual C++ classes (have at least on virtual
function - hence a VMT) with single inheritance (single VMT with virtual
functions at offset 0). Th
I don't know what FPC does with member functions, but Delphi does not
export them. You cannot put a member function in the export part of a
library. You have to create a wrapper (normal function with Self as the
first argument) and then export the wrapper. So, if you happen to have a
good class A
Further reading on some limited portability of C++ classes into Delphi:
http://www.rvelthuis.de/articles/articles-cppobjs.html
Take a specific look at the second part, with pure virtual classes. The
trouble is it only works for virtual C++ classes (have at least on virtual
function - hence a
Op Mon, 22 Jan 2007, schreef Felipe Monteiro de Carvalho:
> So, basically, what I mean with this is: What is needed to add C++
> linking to Free Pascal? It seams to me that it should be easy, we just
> need to understand C++ name mangling and choose a sintax to implement
> it. Maybe something li
The simple answer is that you cannot reliably mix object oriented
langugages without severe portability issues and without loosing basic
functionality: polymorphism. You simply cannot extend the functionality of
a class written in one language from another language.
ON THE LINKING PART: all
Hello,
I was studing how to write the system unit for Symbian OS, and
everything on Symbian is C++, so you actually import lot´s of methods
from classes, not procedures. So I decided to study the task of
linking from Free Pascal to C++
Maybe it´s easy to be implemented, and that would be very ni
19 matches
Mail list logo
