Re: [fpc-pascal] Interface performance

> On Nov 12, 2016, at 3:29 PM, Sven Barth wrote: > Avoid this casting by storing the interface reference. Will make your life > much easier and your code more maintainable. Yes storing the interface works and seems to be the best solution for now. I did learn that

Re: [fpc-pascal] Interface performance

On 11/11/2016 10:14 PM, Ryan Joseph wrote: Arr := TArray.Create; Obj := ObjInt.GetObject; Arr.AddObject(Obj); [do some stuff] // here the problems start because TArray always returns TObject // and I can’t cast TObject to IMyInterface even though the object // stored in the array does in fact

Re: [fpc-pascal] Interface performance

Am 12.11.2016 04:46 schrieb "Ryan Joseph" : > > > > On Nov 12, 2016, at 3:22 AM, Jonas Maebe wrote: > > > > You're passing a class, not an object. Passing a class that implements an interface to a method that expects that interface should

Re: [fpc-pascal] Interface performance

> On Nov 12, 2016, at 3:22 AM, Jonas Maebe wrote: > > You're passing a class, not an object. Passing a class that implements an > interface to a method that expects that interface should work fine. > Converting a class instance to an interface that it implements is

Re: [fpc-pascal] Interface performance

On 11/11/16 16:28, Ryan Joseph wrote: On Nov 11, 2016, at 8:54 PM, Tony Whyman wrote: If you go back to the FPC documentation, in the User Guide it says "Objects are stored in memory just as ordinary records with an extra field: a pointer to the Virtual Method

Re: [fpc-pascal] Interface performance

> On Nov 11, 2016, at 8:54 PM, Tony Whyman > wrote: > > If you go back to the FPC documentation, in the User Guide it says "Objects > are stored in memory just as ordinary records with an extra field: a pointer > to the Virtual Method Table (VMT)." My

Re: [fpc-pascal] Interface performance

Am 11.11.2016 15:16 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-11-11 10:52, Tony Whyman wrote: > > Someone else may correct me, but with CORBA, I believe you have to > > explicitly add a function to the interface such as > > > > function GetObject: TMyObject; > > > I

Re: [fpc-pascal] Interface performance

On 2016-11-11 10:52, Tony Whyman wrote: > Someone else may correct me, but with CORBA, I believe you have to > explicitly add a function to the interface such as > > function GetObject: TMyObject; I may be wrong too, but I thought, for reliable results, you had to do that for COM and CORBA

Re: [fpc-pascal] Interface performance

Isn’t MyObject2 still pointing to MyObject1? If you go back to the FPC documentation, in the User Guide it says "Objects are stored in memory just as ordinary records with an extra field: a pointer to the Virtual Method Table (VMT)." My understanding is that an interface is stored similarly,

Re: [fpc-pascal] Interface performance

On Friday 11 November 2016 12:08:26 Graeme Geldenhuys wrote: > On 2016-11-11 09:46, Ryan Joseph wrote: > > The string lookup absolutely murders performance (I was using “cobra” > > interfaces) so it can’t be used in some situations. > > If you are talking about the GUID, I'm not sure if you know,

Re: [fpc-pascal] Interface performance

On 11/11/16 10:59, Ryan Joseph wrote: What does memory management even mean for interfaces? I never allocate an interface I just implement it in a class so what’s there to be freed? All these crashes I’m getting suggest memory is being trashed by the compiler at some point without my

Re: [fpc-pascal] Interface performance

> On Nov 11, 2016, at 5:52 PM, Tony Whyman > wrote: > > Someone else may correct me, but with CORBA, I believe you have to explicitly > add a function to the interface such as > > function GetObject: TMyObject; > > and implement as > > function

Re: [fpc-pascal] Interface performance

> On Nov 11, 2016, at 5:44 PM, Tony Whyman > wrote: > > With CORBA you are responsible for freeing the objects that provide an > interface in the same way that you are always responsible for freeing the > objects that you create. If you free an object before

Re: [fpc-pascal] Interface performance

> On Nov 11, 2016, at 6:08 PM, Graeme Geldenhuys > wrote: > > If you are talking about the GUID, I'm not sure if you know, but when > using FPC's CORBA interfaces, you can use a MUCH shorter string which > gives better performance. MSEide even has built-in

Re: [fpc-pascal] Interface performance

On 2016-11-11 09:46, Ryan Joseph wrote: > The string lookup absolutely murders performance (I was using “cobra” > interfaces) so it can’t be used in some situations. If you are talking about the GUID, I'm not sure if you know, but when using FPC's CORBA interfaces, you can use a MUCH shorter

Re: [fpc-pascal] Interface performance

On 11/11/16 10:08, Ryan Joseph wrote: I’m trying your code example now and I get "Class or COM interface type expected, but got “IMyInterface”” when I try to cast with “as”. I was using {$interfaces corba} so maybe that’s the problem? Ooops, as you may guess, I typically work with COM

Re: [fpc-pascal] Interface performance

On 11/11/16 10:25, Ryan Joseph wrote: On Nov 11, 2016, at 4:56 PM, Tony Whyman wrote: 3. To get an object back from an interface you must use the "as" operator. Another point to do with CORBA. The manual says they are not reference counted and programmer needs

Re: [fpc-pascal] Interface performance

> On Nov 11, 2016, at 4:56 PM, Tony Whyman > wrote: > > 3. To get an object back from an interface you must use the "as" operator. This step I was not doing and the “as” operator from an earlier showed it uses a string lookup anyways so it defeated the purpose

Re: [fpc-pascal] Interface performance

> On Nov 11, 2016, at 4:56 PM, Tony Whyman > wrote: > > 3. To get an object back from an interface you must use the "as" operator. Another point to do with CORBA. The manual says they are not reference counted and programmer needs to do book keeping. The crash

Re: [fpc-pascal] Interface performance

On 11/11/16 09:46, Ryan Joseph wrote: I just don’t plain get it. The examples given seem to be a redundant property that could be replaced with a reference the interface itself. Interface delegation is really just an optimisation and is equivalent to defining a set of methods to support the

Re: [fpc-pascal] Interface performance

On 11/11/16 09:46, Ryan Joseph wrote: Just as I got this message I’m running into some inexplicable memory related crashes casting from interfaces to objects and calling methods. Are you sure you can just cast these around like that? The compiler seems to get confused and lose track of what

Re: [fpc-pascal] Interface performance

> On Nov 11, 2016, at 4:31 PM, Tony Whyman > wrote: > > You'll find a couple threads earlier this year in heated debate about > interface delegation and how it is implemented. My conclusion was to avoid > interface delegation - there are just too many traps

Re: [fpc-pascal] Interface performance

Ryan, You'll find a couple threads earlier this year in heated debate about interface delegation and how it is implemented. My conclusion was to avoid interface delegation - there are just too many traps for the unwary. There is also another thread bemoaning some odd features about the

Re: [fpc-pascal] Interface performance

I did some experimenting this morning and found out I could pass references to the interface and call methods directly without using Supports and incurring the string compare penalty. There’s also interface delegation I read about and using “implements” keyword but I couldn’t understand what

[fpc-pascal] Interface performance

Some times when I want to communicate with a class I don’t have full scope access to I’ll use interfaces and the Supports function to call a method. I’ve noticed however that the string compare function that it is used to find the interface in the class is very slow and makes them not useable