[fpc-devel] compile fpc for i386 from a 64 bit machine
Hi... I need to cross-compile an application in a 64 bit environment, (fully working with lazarus 0.9.23 and FPC 2.2.1), for 32 bits archs. I tryed to follow this guide: http://wiki.lazarus.freepascal.org/Cross_compiling But I have the following errors: /home/siteland/lazarus/FPC_2.2.1/compiler/ppc -Ur -Xs -O2 -n -Fui386 -Fusystems -Fu/home/siteland/lazarus/FPC_2.2.1/rtl/units/x86_64-linux -Fii386 -FE. -FUi386/units/x86_64-linux -Cg -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time cutils.pas(148,1) Fatal: There were 4 errors compiling module, stopping This is my arch: Linux myserver 2.6.15-28-amd64-server #1 SMP Wed Jul 18 23:04:02 UTC 2007 x86_64 GNU/Linux Alvise Nicoletti ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Alvise Nicoletti schrieb: Hi... I need to cross-compile an application in a 64 bit environment, (fully working with lazarus 0.9.23 and FPC 2.2.1), for 32 bits archs. I tryed to follow this guide: http://wiki.lazarus.freepascal.org/Cross_compiling But I have the following errors: /home/siteland/lazarus/FPC_2.2.1/compiler/ppc -Ur -Xs -O2 -n -Fui386 -Fusystems -Fu/home/siteland/lazarus/FPC_2.2.1/rtl/units/x86_64-linux -Fii386 -FE. -FUi386/units/x86_64-linux -Cg -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time cutils.pas(148,1) Fatal: There were 4 errors compiling module, stopping This is my arch: Linux myserver 2.6.15-28-amd64-server #1 SMP Wed Jul 18 23:04:02 UTC 2007 x86_64 GNU/Linux Well, as the error says, this is currently not supported. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Op donderdag 29-11-2007 om 10:19 uur [tijdzone +0100], schreef Alvise Nicoletti: Hi... I need to cross-compile an application in a 64 bit environment, (fully working with lazarus 0.9.23 and FPC 2.2.1), for 32 bits archs. I tryed to follow this guide: http://wiki.lazarus.freepascal.org/Cross_compiling But I have the following errors: /home/siteland/lazarus/FPC_2.2.1/compiler/ppc -Ur -Xs -O2 -n -Fui386 -Fusystems -Fu/home/siteland/lazarus/FPC_2.2.1/rtl/units/x86_64-linux -Fii386 -FE. -FUi386/units/x86_64-linux -Cg -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time cutils.pas(148,1) Fatal: There were 4 errors compiling module, stopping This is my arch: Linux myserver 2.6.15-28-amd64-server #1 SMP Wed Jul 18 23:04:02 UTC 2007 x86_64 GNU/Linux Most linux-distubutions do support 32 bit and 64 bit at the same time. So you can just install the 32-bit fpc-compiler on your system, and use this compiler to create 32-bit applications on your 64/32-bit OS. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Florian Klaempfl ha scritto: Alvise Nicoletti schrieb: Hi... I need to cross-compile an application in a 64 bit environment, (fully working with lazarus 0.9.23 and FPC 2.2.1), for 32 bits archs. I tryed to follow this guide: http://wiki.lazarus.freepascal.org/Cross_compiling But I have the following errors: /home/siteland/lazarus/FPC_2.2.1/compiler/ppc -Ur -Xs -O2 -n -Fui386 -Fusystems -Fu/home/siteland/lazarus/FPC_2.2.1/rtl/units/x86_64-linux -Fii386 -FE. -FUi386/units/x86_64-linux -Cg -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time cutils.pas(148,1) Fatal: There were 4 errors compiling module, stopping This is my arch: Linux myserver 2.6.15-28-amd64-server #1 SMP Wed Jul 18 23:04:02 UTC 2007 x86_64 GNU/Linux Well, as the error says, this is currently not supported. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Mhh... what is not supported? The creation of a 32 bit binary file from a 64 bit linux? Is there any other solution? I can also use a pre-compiled one if it comprehends the current bugfixes of fpc... (2.2.1) I have a virtual machine at 32 bits but keeping both updated is hard and buggy... I'd like to crosscompile from that 64 bit one... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Op Thu, 29 Nov 2007, schreef Joost van der Sluis: Most linux-distubutions do support 32 bit and 64 bit at the same time. So you can just install the 32-bit fpc-compiler on your system, and use this compiler to create 32-bit applications on your 64/32-bit OS. Distribution support is not even necessary, for example, we have the i386 version installed on Scenergy (without any 32-bit distro support) and it runs without trouble. Of course you cannot link to external libraries in such case, because they are not installed. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Daniël Mantione ha scritto: Op Thu, 29 Nov 2007, schreef Joost van der Sluis: Most linux-distubutions do support 32 bit and 64 bit at the same time. So you can just install the 32-bit fpc-compiler on your system, and use this compiler to create 32-bit applications on your 64/32-bit OS. Distribution support is not even necessary, for example, we have the i386 version installed on Scenergy (without any 32-bit distro support) and it runs without trouble. Of course you cannot link to external libraries in such case, because they are not installed. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.9/1158 - Release Date: 28/11/2007 21.11 Yes, I have the packages needed to open a 32 bit file in my 64 bits distro (ubuntu-server): . linux32 ia32-libs lib32gcc1 lib32stdc++6 lib32z1 libc6-dev-i386 lib32bz2-dev But the fpc compiler version I'm using have bugfixes introduced by Joost that are needed in my application, so I will also need a 32 bit fpc compiler with that inside it... ... or I am wrong? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Alvise Nicoletti wrote on do, 29 nov 2007: Florian Klaempfl ha scritto: Alvise Nicoletti schrieb: fpcdefs.inc(111,2) Error: User defined: Cross-compiling from non-i386 to i386 is not yet supported at this time cutils.pas(148,1) Fatal: There were 4 errors compiling module, stopping This is my arch: Linux myserver 2.6.15-28-amd64-server #1 SMP Wed Jul 18 23:04:02 UTC 2007 x86_64 GNU/Linux Well, as the error says, this is currently not supported. Mhh... what is not supported? Compiling i386 code with a non-i386 hosted compiler is not supported. It has nothing to do with 32 vs 64 bit (an x86_64 hosted compiler can perfectly create sparc32 or ppc32 code), but with the extended floating point type which we do not support on all non-i386 platformas (although I believe it actually is supported on linux/x86_64 unlike on win64/x86_64, so maybe the check could be refined). Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Op Thu, 29 Nov 2007, schreef Alvise Nicoletti: Yes, I have the packages needed to open a 32 bit file in my 64 bits distro (ubuntu-server): . linux32 ia32-libs lib32gcc1 lib32stdc++6 lib32z1 libc6-dev-i386 lib32bz2-dev But the fpc compiler version I'm using have bugfixes introduced by Joost that are needed in my application, so I will also need a 32 bit fpc compiler with that inside it... ... or I am wrong? Nothing stops you from compiling a 2.2.1 i386 compiler on an x86_64 system. It just needs to be bootstrapped with a ppc386, simply do: make FPC=/path/to/ppc386 CPU_SOURCE=i386 ... and voila. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Graeme Geldenhuys wrote:
So what do I use to create interfaces and classes that implement interfaces?
Which declaration style do I use? Or doesn't it make a difference?
type
ICommand = interface(IInterface)
vs
ICommand = interface(IUnkown)
They are exactly the same ? (D=5 and D=6 compatibility)
ICommand = interface
Under $interfaces com, interface = interface(iunknown)
Now for created classes that implement those interfaces. What base
object do I use?
type
TCommandClass = class(TInterfacedObject, ICommand)
vs
TCommandClass = class(TSomeCustomNonReferenceCountedClass, ICommand)
I am using my own classes that implement _addref, _release and QueryIntf
and am very happy with them. I do use refcounting where I want
(everywhere btw) and don't destroy the instance where I don't want.
You will want to use TInterfacedObject class if you:
1. Want refcounting;
2. Don't want to destroy the instance if the refcount 0 (the object
will raise an exception);
3. Don't need to descend from another class.
4. Will take care with circular references.
Otherwise you will need to create your own class and:
1. implement _addref, _release and QueryIntf if using com interfaces;
2. do nothing if using corba interfaces (I have no idea how an interface
is queried here).
I can't imagine that usig Corba style interfaces that I'm allowed to
use TInterfacedObject as a based class, because TInterfacedObject
implements reference counting. Is there some other base class I'm
supposed to use with Corba style interfaces?
Any class. Afaik corba interfaces doesn't implement a method ?
Does FPC have a Non-Reference counted base class already? It's quite
simple to implement you own, but is stupid if FPC doesn't already have
one.
Err... a class doesn't have refcount, just start with TObject or a
descendant.
Also, do I have to specify {$Interfaces Corba} in every unit I have,
or is it only needed in the using that defines the interface itself?
You need. See eg MSE units.
Basically, is that compiler setting unit based or project (global)
based. Why I ask, is because {$mode xxx} is unit based, not global
across my whole project. So can I mix Reference counted and
Non-Reference counted interface styles in the same project?
Any compiler directive is unit based. The unit where you declared the
interface is what will count here.
I found find any help referencing these issues The help topics on
interfaces and $Interfaces styles are very vague.
Not vague, they was straight to the point imo.
--
Joao Morais
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Daniël Mantione ha scritto: Op Thu, 29 Nov 2007, schreef Alvise Nicoletti: Yes, I have the packages needed to open a 32 bit file in my 64 bits distro (ubuntu-server): . linux32 ia32-libs lib32gcc1 lib32stdc++6 lib32z1 libc6-dev-i386 lib32bz2-dev But the fpc compiler version I'm using have bugfixes introduced by Joost that are needed in my application, so I will also need a 32 bit fpc compiler with that inside it... ... or I am wrong? Nothing stops you from compiling a 2.2.1 i386 compiler on an x86_64 system. It just needs to be bootstrapped with a ppc386, simply do: make FPC=/path/to/ppc386 CPU_SOURCE=i386 ... and voila. Honestly I had some problems to understand the mechanism in this, however, giving that command suppose that you have a /path/to/ppc386 somewhere, and I hadn't. I copyed the binary of my other 32 bit server in the 64 bit server, in the path: /usr/local/lib/fpc/2.2.1/ppc386 And I did, as you said, a: make all FPC=/usr/local/lib/fpc/2.2.1/ppc386 CPU_SOURCE=i386 That seemed to work, it compiled everything, but now I suppose I have to do a make install... But both: make install CPU_TARGET=i386 make install CPU_SOURCE=i386 Gives errors. Where is the created ppc386 file? With I locate I find it there: /home/siteland/lazarus/FPC_2.2.1/compiler/ppc386 And /home/siteland/lazarus/FPC_2.2.1/ is the root path of my compilation. Should I use that as new fpc-compiler for my 32 bit projects? Alvise Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.9/1158 - Release Date: 28/11/2007 21.11 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Joao Morais [EMAIL PROTECTED] wrote: ICommand = interface Under $interfaces com, interface = interface(iunknown) That much I figured, but the question is what does 'interface' default to if Corba style interfaces are used? 1. implement _addref, _release and QueryIntf if using com interfaces; 2. do nothing if using corba interfaces (I have no idea how an interface is queried here). See, this is where the docs can do with some improvement. :) From my bit of testing with Corba style interfaces, you can use the Supports() method which internally uses the QueryInterface() method, so I would imagine you at least need to implement QueryInterface in your own custom interface enabled base class when using Corba style interfaces. As for _addref() and _release(), it's still a mystery to me. I would imagine I don't need those, but then I have no idea what the base interface looks like for Corba. No documentation mentions wat it is! Any class. Afaik corba interfaces doesn't implement a method ? It must, because I can query the interface using Supports(). Does FPC have a Non-Reference counted base class already? It's quite simple to implement you own, but is stupid if FPC doesn't already have one. Err... a class doesn't have refcount, just start with TObject or a descendant. I meant a class that supports interfaces. TObject doesn't for COM. Again, no idea for CORBA. You need. See eg MSE units. MSEgui implements it's own custom TNullInterfacedObject class which isn't reference counted with the usual IUnkown signature. This is my main question. What is the required functions for CORBA? I know the following is required for IUnkown. protected function QueryInterface(const IID: TGUID; out Obj): longint; stdcall; function _AddRef: longint; stdcall; function _Release: longint; stdcall; Not vague, they was straight to the point imo. Could you then please point me to the correct documentation covering all these questions. I can't seem to find that information anywhere. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Joao Morais [EMAIL PROTECTED] wrote:
Any class. Afaik corba interfaces doesn't implement a method ?
OK, I wrote a quick test app. Added {$Interfaces Corba} in each unit
just to be save.
I declared two interfaces as follows:
type
ICommand = interface
['{28D72102-D883-41A1-9585-D86B24D9C628}']
procedure Execute;
end;
ICommandHolder = interface
['{695BA6E1-1120-42D4-A2C3-54F98D5CDA46}']
functionGetCommand: ICommand;
procedure SetCommand(ACommand: ICommand);
end;
I then defined a class implementing ICommand as follows taking your
suggestion of using TObject:
TAddCommand = class(TObject, ICommand)
private
FMemo: TfpgMemo;
public
constructor Create(AMemo: TfpgMemo); reintroduce;
procedure Execute;
end;
I then wrote the following code to see if I could query for a
supported interface.
var
cmd: ICommand;
ins: TAddCommand;
begin
ins := TAddCommand.Create(memName1);
if Supports(ins, ICommand, cmd) then
begin
writeln('It worked');
cmd.Execute;
end;
ins.Free;
end;
Well, the 'It worked' never appears and the cmd.Execute is never
fired, so it's still a mystery how CORBA interfaces work. I'll see if
Delphi help maybe mentions something.
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Graeme Geldenhuys wrote:
type
ICommand = interface
['{28D72102-D883-41A1-9585-D86B24D9C628}']
procedure Execute;
end;
What is the point of defining a GUID for a non-COM interface?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
I then wrote the following code to see if I could query for a supported interface. ... Well, the 'It worked' never appears and the cmd.Execute is never fired, so it's still a mystery how CORBA interfaces work. I'll see if Delphi help maybe mentions something. You can assign from an object to a (non-COM) interface variable: var Obj: TSomeObject; Intf: ISomeInterface; begin ... Intf := Obj as ISomeInterface; But once you got a (non-COM) interface you are stuck with it. As there is no QueryInterface method available there is no way to get from an interface to another interface implemented by the same object (Or back to the object for that matter). As for why your call to Supports fails, Supports internally gets Iinterface (if implemented) from the object and then calls QueryInterface to get a reference to the interface you actually asked for. That naturally only works with COM interfaces. Cheers, Thorsten ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Thorsten Engler [EMAIL PROTECTED] wrote: to another interface implemented by the same object (Or back to the object for that matter). I guess to get back to the Obj instance, you could let your ISomething interface implement function Instance which returns the Obj instance. That's a old trick used in Delphi code with COM interfaces. As for why your call to Supports fails, Supports internally gets Iinterface (if implemented) from the object and then calls QueryInterface to get a reference to the interface you actually asked for. That naturally only works with COM interfaces. Well in that case, shouldn't the compiler give me a error when I use Corba interfaces and try and use the Supports() method. That would be the logical thing wouldn't it, since Supports() would then *never* work with true CORBA interfaces. Don't give the clueless developer false hope. :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Micha Nelissen [EMAIL PROTECTED] wrote:
type
ICommand = interface
['{28D72102-D883-41A1-9585-D86B24D9C628}']
procedure Execute;
end;
What is the point of defining a GUID for a non-COM interface?
Beats me, I thought that might be needed for querying a object for
interfaces it supports... As far as CORBA is concerned, I'm just
shooting in the dark here... Information on CORBA usage is limited
and I can't find any FPC code examples to give me hints. It seems
quite useless having the Corba support in FPC, if everything related
to Interfaces requires COM methods.
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Thorsten Engler [EMAIL PROTECTED] wrote:
You can assign from an object to a (non-COM) interface variable:
var
Obj: TSomeObject;
Intf: ISomeInterface;
begin
...
Intf := Obj as ISomeInterface;
[ I can't find the message I just sent in my Outbox, so here it is again. ]
I tried what you said and got a error at runtime.
[EMAIL PROTECTED]:command_interface$ ./test
An unhandled exception occurred at $080553C1 :
EInvalidCast : Invalid type cast
and the code...
var
cmd: ICommand;
holder: ICommandHolder;
ins: TAddCommand;
begin
ins := TAddCommand.Create(memName1);
cmd := ins as ICommand;
if Assigned(cmd) then
begin
writeln('It worked');
cmd.Execute;
end;
ins.Free;
end;
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Graeme Geldenhuys wrote: Beats me, I thought that might be needed for querying a object for interfaces it supports... As far as CORBA is concerned, I'm just shooting in the dark here... Information on CORBA usage is limited and I can't find any FPC code examples to give me hints. It seems quite useless having the Corba support in FPC, if everything related to Interfaces requires COM methods. Think of Corba-styled interfaces as about interfaces without COM glue, not just as about interfaces without refcounting. To get runtime typecasting features, you have to implement it yourself. OTOH, you are free to implement anything you want. As for non-refcounted interfaced base class, you may want to use TComponent. Of course, it has some overhead compared with TInterfacedObject, but its features are quite useful in almost every application. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Sergei Gorelkin schreef:
Graeme Geldenhuys wrote:
Beats me, I thought that might be needed for querying a object for
interfaces it supports... As far as CORBA is concerned, I'm just
shooting in the dark here... Information on CORBA usage is limited
and I can't find any FPC code examples to give me hints. It seems
quite useless having the Corba support in FPC, if everything related
to Interfaces requires COM methods.
Think of Corba-styled interfaces as about interfaces without COM glue,
not just as about interfaces without refcounting. To get runtime
typecasting features, you have to implement it yourself. OTOH, you are
free to implement anything you want.
As for non-refcounted interfaced base class, you may want to use
TComponent. Of course, it has some overhead compared with
TInterfacedObject, but its features are quite useful in almost every
application.
Given:
type
TAddCommand = class(TBaseCommnad, ICommand)
bla
end;
Does the compiler store somewhere that that TAddCommand implements ICommand? I
assume it does the compile time check that TAddCommand implements all ICommands
methods, but is there something similar provided by the compiler (or RTTI) which can
be used to do something like
ACommnd := TAddCommand.Create;
if (ACommand is TBaseCommand) then
writeln('This works');
if (ACommand.InheritsFrom('TBaseCommand') then
writeln('This works');
if (ACommand is ICommand) then
writeln('I don't know if this works, but I would expect it if you consider
interfaces similar to abstract base classes');
if (ACommand.Implements(ICommand)) then
writeln('I don't know if this works, but it is similar to the InheritsFrom
case');
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Sergei Gorelkin [EMAIL PROTECTED] wrote:
Think of Corba-styled interfaces as about interfaces without COM glue,
not just as about interfaces without refcounting. To get runtime
typecasting features, you have to implement it yourself. OTOH, you are
free to implement anything you want.
So everything I have read up till now about Interfaces are all just
based on COM interfaces! I thought seeing that I can't find info in
FPC's docs, I would look at Kylix 3 help. Seeing that Kylix is not
dependent on COM, in should have a neutral (platfrom independant)
interfaces implementation. Yet all the docs in Kylix mentions
Supports(), QueryInterface() and TInterfacedObject, so no matter the
platform, it seems everything about interfaces are based on
Microsoft's COM design. Wow!
Can somebody confirm the following
I read in a message thread from 2005 that when you use Corba style
interfaces, interfaces are also not allowed to inherit from each
other. Is this correct?
{$Interfaces Corba}
type
MyInterfaceA = Interface
...
end;
MyInterfaceB = Interface(MyInterfaceA) ===Not allowed??
...
end;
If the above it true, this is another thing that could be added to the
FPC docs. Maybe we should start a Using Interfaces chapter in the
Programmers Guide or the Language Guide.
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Graeme Geldenhuys [EMAIL PROTECTED] wrote:
I read in a message thread from 2005 that when you use Corba style
interfaces, interfaces are also not allowed to inherit from each
other. Is this correct?
If that is supposed to be true, then we have a problem in FPC 2.2.0
I've just written the following and compiled the unit without any
compiler errors.
{$Interfaces Corba}
type
IntfA = Interface
function MyFunctionA: integer;
end;
IntfB = Interface(IntfA)
function MyFunctionB: String;
end;
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Alvise Nicoletti wrote: Daniël Mantione ha scritto: Op Thu, 29 Nov 2007, schreef Alvise Nicoletti: Yes, I have the packages needed to open a 32 bit file in my 64 bits distro (ubuntu-server): . linux32 ia32-libs lib32gcc1 lib32stdc++6 lib32z1 libc6-dev-i386 lib32bz2-dev But the fpc compiler version I'm using have bugfixes introduced by Joost that are needed in my application, so I will also need a 32 bit fpc compiler with that inside it... ... or I am wrong? Nothing stops you from compiling a 2.2.1 i386 compiler on an x86_64 system. It just needs to be bootstrapped with a ppc386, simply do: make FPC=/path/to/ppc386 CPU_SOURCE=i386 ... and voila. Honestly I had some problems to understand the mechanism in this, however, giving that command suppose that you have a /path/to/ppc386 somewhere, and I hadn't. I copyed the binary of my other 32 bit server in the 64 bit server, in the path: /usr/local/lib/fpc/2.2.1/ppc386 And I did, as you said, a: make all FPC=/usr/local/lib/fpc/2.2.1/ppc386 CPU_SOURCE=i386 That seemed to work, it compiled everything, but now I suppose I have to do a make install... But both: make install CPU_TARGET=i386 make install CPU_SOURCE=i386 try make install CPU_SOURCE=i386 FPC=/path/to/your/fresh/compiled/ppc386 Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Marc Weustink wrote: Micha Nelissen wrote: Marc Weustink wrote: How would you get a corba interface from a class where this class implements one or more corba interfaces ? They somehow need to be identified. AObject as ICorbaInterface ? And how does the underlying code do the lookup in the interfaces table? Perhaps it only works if the AObject is a descendent of the class. Or use an interface vmt or so? I don't care about it, just like I don't care about how as TDescendent works internally. Mica ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Marc Weustink wrote: How would you get a corba interface from a class where this class implements one or more corba interfaces ? They somehow need to be identified. AObject as ICorbaInterface ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Graeme Geldenhuys wrote: On 29/11/2007, Thorsten Engler [EMAIL PROTECTED] wrote: to another interface implemented by the same object (Or back to the object for that matter). I guess to get back to the Obj instance, you could let your ISomething interface implement function Instance which returns the Obj instance. That's a old trick used in Delphi code with COM interfaces. As for why your call to Supports fails, Supports internally gets Iinterface (if implemented) from the object and then calls QueryInterface to get a reference to the interface you actually asked for. That naturally only works with COM interfaces. Well in that case, shouldn't the compiler give me a error when I use Corba interfaces and try and use the Supports() method. That would be the logical thing wouldn't it, since Supports() would then *never* work with true CORBA interfaces. Don't give the clueless developer false hope. :-) Hmm... I reported something similar in the past, which is fixed: http://www.freepascal.org/mantis/view.php?id=6796 (also 6797 and 6798 are somewhat related to this topic) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Micha Nelissen wrote:
Graeme Geldenhuys wrote:
type
ICommand = interface
['{28D72102-D883-41A1-9585-D86B24D9C628}']
procedure Execute;
end;
What is the point of defining a GUID for a non-COM interface?
How would you get a corba interface from a class where this class
implements one or more corba interfaces ? They somehow need to be
identified.
related to this are:
http://www.freepascal.org/mantis/view.php?id=6797
http://www.freepascal.org/mantis/view.php?id=6798
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Micha Nelissen wrote: Marc Weustink wrote: How would you get a corba interface from a class where this class implements one or more corba interfaces ? They somehow need to be identified. AObject as ICorbaInterface ? And how does the underlying code do the lookup in the interfaces table? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Marc Weustink [EMAIL PROTECTED] wrote:
http://www.freepascal.org/mantis/view.php?id=6798
I can confirm that this doesn't work
{$Interfaces Corba}
var
cmd: ICommand;
holder: ICommandHolder;
ins: TAddCommand;
begin
ins := TAddCommand.Create(memName1);
ins.GetInterface(ICommand, cmd);
if cmd nil then
begin
writeln('It worked');
cmd.Execute;
end;
ins.free;
end;
it worked never gets printed.
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Micha Nelissen wrote: Marc Weustink wrote: Micha Nelissen wrote: Marc Weustink wrote: How would you get a corba interface from a class where this class implements one or more corba interfaces ? They somehow need to be identified. AObject as ICorbaInterface ? And how does the underlying code do the lookup in the interfaces table? Perhaps it only works if the AObject is a descendent of the class. Which class ? Or use an interface vmt or so? I don't care about it, just like I don't care about how as TDescendent works internally. I only know that a corba interface needs to be identified somehow otherwise it cant be looked up. (which can't atm) Be it through GUID, name or vtm. Anyway I'm not that deep into CORBA, but how do interfacing parties agree on the type/contract (or how do you call it) of corba interfaces? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Graeme Geldenhuys wrote:
On 29/11/2007, Marc Weustink [EMAIL PROTECTED] wrote:
http://www.freepascal.org/mantis/view.php?id=6798
I can confirm that this doesn't work
{$Interfaces Corba}
var
cmd: ICommand;
holder: ICommandHolder;
ins: TAddCommand;
begin
ins := TAddCommand.Create(memName1);
ins.GetInterface(ICommand, cmd);
if cmd nil then
begin
writeln('It worked');
cmd.Execute;
end;
ins.free;
end;
it worked never gets printed.
Yes, you cannot query corba objects, since they don't have a
QueryInterface method.
However cmd := ins; should work.
Marc
PS.
IMO borland screwed up here when they introduced IInterface = IUnknown.
It was IMo cleaner (and you can mix interface types) when they declared
it like:
type
IInterface = interface
end;
IUnknown = interface(IInterface)
_addref...
_release
Query
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Marc Weustink [EMAIL PROTECTED] wrote: I only know that a corba interface needs to be identified somehow otherwise it cant be looked up. (which can't atm) Be it through GUID, name or vtm. So based on all these discussions on Corba interfaces, I can only make one conclusion. FPC's Corba interfaces support is not ready yet. So I'll stay with COM based interfaces and remove reference counting if required. BTW: I searched the FPC and Lazarus code and couldn't find any TNonRefCountedObject class (or something with a similar name). I have seen many implementations of such a class on the internet and everybody seems to implement it in the same way. Wouldn't it then be a good idea to add such a class into the RTL for convenience. Why must every developer always reinvent the wheel if they want non-reference counted COM interfaces. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
AObject as ICorbaInterface ? And how does the underlying code do the lookup in the interfaces table? There is no lookup required for this. An as cast from object to interface is only allowed (at least in Delphi) if the compiler can statically at compiletime determine that the type of the AObject variable implements that interface. Objects implement interfaces by having a pointer to the VMT of for the implemented interface in their instance data. So the above cast should get compiled into somethinge like: If Aobject = nil then Intf := nil Else Intf := ICorbaInterface(IntPtr(Aobject) + OffsetOfICorbaInterface); There is no need for a GUID in this case. (And in Delphi, using an as cast like this is the way how you get a reference to an interface that has no GUID.) It's important to mention here that: Intf := AObject as ISomeInterface; and Supports(Aobject, ISomeInterface, Intf); Do very different things. The first one resolves the offset that needs to be applied to AObject to get to ISomeInterface at compiletime based on the type of the variable (not the type of the actual instance which is only known at runtime). The 2nd one uses a call to Aobject.GetInterface, passing in the GUID of Iinterface and then calls QueryInterface with the GUID of ISomeInterface on that. That can lead to interesting effects: Type TObjectA = class(TInterfacedObject, ISomeInterface) procedure SomeMethod; //not virtual! end; TObjectB = class(TObjectA, ISomeInterface) procedure SomeMethod; end; Var Obj : TObjectA; IntfA : ISomeInterface; IntfB : ISomeInterface; Begin Obj := TObjectB.Create; IntfA := Obj as ISomeInterface; Supports(Obj, ISomeInterface, IntfB); IntfA.SomeMethod; //calls TObjectA.SomeMethod IntfB.SomeMethod; //calls TObjectB.SomeMethod End; Most of the above assumes you are working with COM style interfaces (the only type of interface supported by Delphi/Kylix which doesn't have any support at compiler level for CORBA interfaces). For CORBA interfaces in FPC the only thing that should/can work is casting from an object variable to an interface type using as if the compiler can statically at compiletime determine the correct offset to apply to the object pointer to get to the interface VMT and maybe support casting an interface to one of it's parent interfaces. There is no way how is, as or Supports could be implemented for such interfacces. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 29/11/2007, Marc Weustink [EMAIL PROTECTED] wrote: type IInterface = interface end; IUnknown = interface(IInterface) _addref... _release Query end; After all these messages, that does seem like the better solution. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
IMO borland screwed up here when they introduced IInterface = IUnknown. No they didn't. It was IMo cleaner (and you can mix interface types) There are no different types of interfaces in Delphi/Kylix. Even if there were (like there are in FPC) you can never ever mix them. when they declared it like: type IInterface = interface end; IUnknown = interface(IInterface) _addref... _release Query end; Lets assume we had that definition. Now look at this code: Var Intf : Iinterface; Unk : Iunknown; Begin Unk := //... Get some Iunknown from somewhere Intf := Unk; //would be valid as Iunknown derives from Iinterface //but as Intf doesn't have an AddRef it can't be called. Unk := nil; //Unk has _release which is called and frees the object behind the interface) //Intf now points to a freed object End; Beside that, that's the point of such a castrated Iinterface? What can you do with it? No QueryInterface, so you can't get from there to anything else. The as and is operators depend on either methods of Tobject (which can't be reached) or information which is stored at negative offset in the VMT (which isn't present for an interface VMT) so they can't be used either. Cheers, Thorsten ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Marc Weustink ha scritto: Alvise Nicoletti wrote: Daniël Mantione ha scritto: Op Thu, 29 Nov 2007, schreef Alvise Nicoletti: Yes, I have the packages needed to open a 32 bit file in my 64 bits distro (ubuntu-server): . linux32 ia32-libs lib32gcc1 lib32stdc++6 lib32z1 libc6-dev-i386 lib32bz2-dev But the fpc compiler version I'm using have bugfixes introduced by Joost that are needed in my application, so I will also need a 32 bit fpc compiler with that inside it... ... or I am wrong? Nothing stops you from compiling a 2.2.1 i386 compiler on an x86_64 system. It just needs to be bootstrapped with a ppc386, simply do: make FPC=/path/to/ppc386 CPU_SOURCE=i386 ... and voila. Honestly I had some problems to understand the mechanism in this, however, giving that command suppose that you have a /path/to/ppc386 somewhere, and I hadn't. I copyed the binary of my other 32 bit server in the 64 bit server, in the path: /usr/local/lib/fpc/2.2.1/ppc386 And I did, as you said, a: make all FPC=/usr/local/lib/fpc/2.2.1/ppc386 CPU_SOURCE=i386 That seemed to work, it compiled everything, but now I suppose I have to do a make install... But both: make install CPU_TARGET=i386 make install CPU_SOURCE=i386 try make install CPU_SOURCE=i386 FPC=/path/to/your/fresh/compiled/ppc386 Thank you, that seemed to work. However, 1) going on lazarus and choosing ppc386 as compiler, I got no errors (also the project in the code section of compiler options is set to i386). 2) the project compiles well 3) I fail during the link process with that error: /usr/bin/ld: skipping incompatible /usr/lib/crti.o when searching for /usr/lib/crti.o The file /usr/lib/crti.o exists. In the guide: http://wiki.lazarus.freepascal.org/Cross_compiling something about a ld script was written, I created the scripts as indicated (plus chmod +x), but I have not launched them. I have to do something related to this? Alvise Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
Thorsten Engler wrote: IMO borland screwed up here when they introduced IInterface = IUnknown. No they didn't. IMO :) It was IMo cleaner (and you can mix interface types) There are no different types of interfaces in Delphi/Kylix. Even if there were (like there are in FPC) you can never ever mix them. when they declared it like: type IInterface = interface end; IUnknown = interface(IInterface) _addref... _release Query end; Lets assume we had that definition. Now look at this code: Var Intf : Iinterface; Unk : Iunknown; Begin Unk := //... Get some Iunknown from somewhere Intf := Unk; //would be valid as Iunknown derives from Iinterface //but as Intf doesn't have an AddRef it can't be called. Unk := nil; //Unk has _release which is called and frees the object behind the interface) //Intf now points to a freed object End; True, you need to know what you are doing. It is the same as P: Pointer; P ;= Unk; (OK accessing methods is more dificult) Beside that, that's the point of such a castrated Iinterface? What can you do with it? The same what you want to do with a CORBA interface ? No QueryInterface, so you can't get from there to anything else. You can say the same one you have assigned an object to an interface, no way back to the object. So once you assign a iunkown or object to the stripped iinterface you can only stay there. If you didn't want that, you shouldn't have used a iinterface in the first place (or cast it as you would have done with a pointer). The as and is operators depend on either methods of Tobject (which can't be reached) or information which is stored at negative offset in the VMT (which isn't present for an interface VMT) so they can't be used either. You can do 'is' and 'as' on IUnknown descendants now only too, so no difference. The only advantage is that you *can* mix reference counted and non reference counted interfaces, where the non reference counted don't require the overhead of an additional exception handler. There are cases I only want the polymorf behaviour of interfaces and not the refercing Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Alvise Nicoletti wrote: Marc Weustink ha scritto: Alvise Nicoletti wrote: Daniël Mantione ha scritto: Op Thu, 29 Nov 2007, schreef Alvise Nicoletti: Yes, I have the packages needed to open a 32 bit file in my 64 bits distro (ubuntu-server): . linux32 ia32-libs lib32gcc1 lib32stdc++6 lib32z1 libc6-dev-i386 lib32bz2-dev But the fpc compiler version I'm using have bugfixes introduced by Joost that are needed in my application, so I will also need a 32 bit fpc compiler with that inside it... ... or I am wrong? Nothing stops you from compiling a 2.2.1 i386 compiler on an x86_64 system. It just needs to be bootstrapped with a ppc386, simply do: make FPC=/path/to/ppc386 CPU_SOURCE=i386 ... and voila. Honestly I had some problems to understand the mechanism in this, however, giving that command suppose that you have a /path/to/ppc386 somewhere, and I hadn't. I copyed the binary of my other 32 bit server in the 64 bit server, in the path: /usr/local/lib/fpc/2.2.1/ppc386 And I did, as you said, a: make all FPC=/usr/local/lib/fpc/2.2.1/ppc386 CPU_SOURCE=i386 That seemed to work, it compiled everything, but now I suppose I have to do a make install... But both: make install CPU_TARGET=i386 make install CPU_SOURCE=i386 try make install CPU_SOURCE=i386 FPC=/path/to/your/fresh/compiled/ppc386 Thank you, that seemed to work. However, 1) going on lazarus and choosing ppc386 as compiler, I got no errors (also the project in the code section of compiler options is set to i386). 2) the project compiles well 3) I fail during the link process with that error: /usr/bin/ld: skipping incompatible /usr/lib/crti.o when searching for /usr/lib/crti.o The file /usr/lib/crti.o exists. you should have a libdir with 32bit libs and a libdir with 64 bit libs Edit your fpc.cfg and search for lines beginning with -Fl Add similar lines pointing to the 32bit libdir. In the guide: http://wiki.lazarus.freepascal.org/Cross_compiling something about a ld script was written, I created the scripts as indicated (plus chmod +x), but I have not launched them. I have to do something related to this? the compiler will do when needed. You already got beyond that: ld is called (since it complains that it cannot find valid libs) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compile fpc for i386 from a 64 bit machine
Op Thu, 29 Nov 2007, schreef Alvise Nicoletti: I added a /usr/lib32 link to the fpc.cfg, however I have no crti.o in the /usr/lib32/ folder. I got the same error trying to cross-compile to a i386 target. /usr/lib/crti.o is a ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped Who should compile/provide that library at 32 bits? Your distro. Daniël p.s. so I will have to change the fpc.cfg every time I want to crosscompile? or there is a IFDEF(initive) solution? You can add both directories, the linker will skip the unusable one. If constructions are also possible by the way. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] interfaces vs classes in dll
Lazarus has the IDEIntf, the API for IDE plugins. What is better in this case: classes or interfaces? What if someday there are packages? What if someday there is a closed source dll plugin? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] interfaces vs classes in dll
Mattias Gaertner wrote: Lazarus has the IDEIntf, the API for IDE plugins. What is better in this case: classes or interfaces? What if someday there are packages? What if someday there is a closed source dll plugin? 3x Interfaces (you need a shared memmanager in this case) Additional advantage with interfaces is that you can have different versions of an interface implemented by the same class I can imagine that some interface needs to be extended someday, then adding a newer version (=copy + new guid + extention) of the interface won't break older plugins. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] interfaces vs classes in dll
On Thu, 29 Nov 2007, Mattias Gaertner wrote: Lazarus has the IDEIntf, the API for IDE plugins. What is better in this case: classes or interfaces? Classes: - No reference counting mess. - Easier to grasp conceptually. - You can use ansistrings. Interfaces require widestrings. (olestrings to be exact) What if someday there are packages? It'll work transparantly. What if someday there is a closed source dll plugin? If it is a package, there is no problem. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On Thursday 29 November 2007 11.52, Graeme Geldenhuys wrote:
Also, do I have to specify {$Interfaces Corba} in every unit I have,
or is it only needed in the using that defines the interface itself?
You need. See eg MSE units.
The {$interfaces corba} in every MSEgui unit is because a FPC bug.
http://www.freepascal.org/mantis/view.php?id=6690
It is fixed now, I will remove the no more needed {$interfaces corba} soon.
MSEgui implements it's own custom TNullInterfacedObject class which
isn't reference counted with the usual IUnkown signature. This is my
main question. What is the required functions for CORBA? I know the
following is required for IUnkown.
tnullinterfacedobject is needed in MSEgui for Delphi compatibility because
Delphi has no corba style interfaces.
I think tobject.getinterface should work with corba interfaces too:
http://www.freepascal.org/mantis/view.php?id=6036
MSEgui has a workaround to query corba style interfaces from typeinfo, please
use the function getcorbainterface from lib/common/kernel/mseclasses.pas.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] interfaces vs classes in dll
Michael Van Canneyt пишет: On Thu, 29 Nov 2007, Mattias Gaertner wrote: Lazarus has the IDEIntf, the API for IDE plugins. What is better in this case: classes or interfaces? Classes: - No reference counting mess. - Easier to grasp conceptually. In plugin dll? - You can use ansistrings. Interfaces require widestrings. (olestrings to be exact) Who told you this? Interface com object What if someday there are packages? It'll work transparantly. What if someday there is a closed source dll plugin? If it is a package, there is no problem. And even after extending class old class dependant plugins will work? How? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On Friday 30 November 2007 08.21, Graeme Geldenhuys wrote: On 30/11/2007, Martin Schreiber [EMAIL PROTECTED] wrote: tnullinterfacedobject is needed in MSEgui for Delphi compatibility because Delphi has no corba style interfaces. So basically you want to use interfaces without reference counting. What other benefits did you see to make you decide to use Corba interfaces instead of COM interfaces? Why Corba over COM style? It seems to me the COM interface implementation in FPC is a lot more stable and with more working features. I'm interested in interfaces, but not interested in reference counting. So I will rather use COM interfaces for now and TNonRefCountingObject (same as TNullInterfacedObject) as my base class to get interface support. I gather that's how MSEgui works under Delphi? Why didn't you do the same under FPC? Performance reasons. To use COM interfaces and to ignore reference counting calls in TNonRefCountingObject is no good solution. With the MSEgui getcorbainterface function you can use corba style interfaces until FPC has working getinterface for them. I think tobject.getinterface should work with corba interfaces too: http://www.freepascal.org/mantis/view.php?id=6036 It doesn't look like that is going to be fixed any time soon. It was reported in 2005-06-14 and still hasn't even been acknowledged! :-) Reference counted widestrings is another theme: http://www.freepascal.org/mantis/view.php?id=6060 And I'd like to remember the 'friend units' where protected class members are accessible in order to avoid the ugly and memory wasting fake class definitions implementation type tsomeclass1 = class(tsomeclass) end; [] with tsomeclass1(someclassinstance) do begin end; Packages support and faster compiling are on my wishlist too... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$Interfaces Corba} and TInterfacedObject
On 30/11/2007, Martin Schreiber [EMAIL PROTECTED] wrote: tnullinterfacedobject is needed in MSEgui for Delphi compatibility because Delphi has no corba style interfaces. So basically you want to use interfaces without reference counting. What other benefits did you see to make you decide to use Corba interfaces instead of COM interfaces? Why Corba over COM style? It seems to me the COM interface implementation in FPC is a lot more stable and with more working features. I'm interested in interfaces, but not interested in reference counting. So I will rather use COM interfaces for now and TNonRefCountingObject (same as TNullInterfacedObject) as my base class to get interface support. I gather that's how MSEgui works under Delphi? Why didn't you do the same under FPC? I think tobject.getinterface should work with corba interfaces too: http://www.freepascal.org/mantis/view.php?id=6036 It doesn't look like that is going to be fixed any time soon. It was reported in 2005-06-14 and still hasn't even been acknowledged! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
