As far as I remember, Delphi 5 and on has an IDL compiler included,
I suppose same is used to generate an interface unit when you do "import
type library". Is this possible with TP, too ?
and can generate IDL code from an Object Pascal hierarchy.
I suppose this is true and necessary when cr
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.
Can you point me to previous discussion of this? Or perhaps a short
expla
On 1/22/07, Daniël Mantione <[EMAIL PROTECTED]> wrote:
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.
Can you point me
Yes, this is the original purpose of interfaces in Delphi 3 and later:
reuse object code from different languages/executables through COM/DCOM or
CORBA. Both define standards for RPC (Remote procedure calling) and
passing arguments (type and size). An interface only exports member
functions
On Tue, 23 Jan 2007 08:36:13 -0200
"Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> wrote:
> On 1/23/07, Bogusław Brandys <[EMAIL PROTECTED]> wrote:
> > If libraries are using pure C then you are lucky.If C++ ,then the only
> > reasonable way for me is a thin wrapper DLL(s) :-(
>
> But imagine i
To clarify a bit...
Peter Popov wrote:
A
C++ class CANNOT have a virtual destructor (the VMT is killed when you
call delete, before the class' destructor is called).
Nope. Virtual destructors exist in C++, moreover good practice is to make
destructor virtual if any other method is virtual
>
> Thanks for the clarifying statement, Peter
>
> I's obvious that linking Object Pascal and C++ in that way is not possible.
>
> OTOH, is interfaces not invented for object based inter-language
> communication ?
Yes. But between willing partners, not for OOP language A to be able to
access a
Thanks for the clarifying statement, Peter
I's obvious that linking Object Pascal and C++ in that way is not possible.
OTOH, is interfaces not invented for object based inter-language
communication ?
So an interface based DLL layer, converting the C++ API of the OS to
interfaces FP could us
On 1/23/07, Bogusław Brandys <[EMAIL PROTECTED]> wrote:
If libraries are using pure C then you are lucky.If C++ ,then the only
reasonable way for me is a thin wrapper DLL(s) :-(
But imagine if we require a dll to create apps for a operating system.
omg, that would look like vb!!! =)
It´s a no-
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
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
27 matches
Mail list logo
