[fpc-pascal] interface "is" patch (finished and included) - correction on my answer
ml at brainwashers.org
ml at brainwashers.org
Sat Apr 2 18:01:52 CEST 2005
1. ANSWER ON YOUR QUESTION
==========================
Sorry, my previous answer was completely wrong. This one should do the trick (if
it doesn't compile please understand that I'm on vacation without access to my
computers and fpc is not installed here). Again sorry for my mistake
Refcount works with := , but it doesn't work correctly with GetInterface,
QueryInterface and Supports. I the little stupid me send you example for :=???
I had to find a decent non OSX machine, the only machine available was OSX (and
I hate OSX).
RefCount isn't handled correctly if guid <> 0, obviously tests were for
guid 0 only (either when I create guid with md5 or specify in interface
type as {C35224FA-ED88-0D1C-A4D2-FCF91AC4C776})
// snip =========================================================
type
IA = interface
['{C35224FA-ED88-0D1C-A4D2-FCF91AC4C776}']
procedure A;
end;
TA = class(TInterfacedObject,IA)
procedure A;
end;
procedure TA.A;
begin
end;
var
a,aa: IA;
b:TA;
begin
b := TA.Create;
Writeln('ref:', (b as TInterfacedObject).RefCount); //count=0
a := obj; aa := (a as IA);
Writeln('ref:', (b as TInterfacedObject).RefCount); //count=3
a := b;
Supports(a, IA, aa);
b.GetInterface(IA, aa);
b.GetInterface(IA, aa);
b.GetInterface(IA, aa);
Writeln('ref:', (b as TInterfacedObject).RefCount); //count=7
end.
// snip =========================================================
OUTPUT:
ref:0
ref:3
ref:7
I specified wrong before, getinterface isn't called for a := b so error is not
present there. If those three lines are deleted output is correct.
OUTPUT (after patch):
ref:0
ref:2
ref:2
2. PROBLEMATIC WORKING OF "as"
==============================
This error is present in "as" only
I would like to ask again (about refcount) is:
a := (b as IA); // works
aa := (b as IA); // works
but as soon as you invoke again
a := (b as IA);
or
aa := (b as IA);
it always decrements one. Funny thing is that this doesn't happen the first
time, but any later try to set the same variable decrements one and
doesn't stay the same as it should. (and that only happens with "as")
This wouldn't be a problem if that wouldn't exclude using it like
(c as IA).A;
(c as IA).B;
Any idea why this would happen'???
3. COMPILER DIRECTIVES
======================
Ok, I tryed "is" on Delphi and saw the difference. Patch will be corrected to
your likes (class to class checking).
Is there any mode present (I mean like objfpc, delphi), something like "relaxed"
I would correct patch in a way that if not "relaxed or something else mode" is
present, use delphi strict compiler type testing, else use the relaxed types as
they are now in my "in" implementation.
This doesn't mean that patch won't be corrected if I won't like the answer.
Patch (that works just like delphi) will be on Sunday when I get back from
vacation. I would just like to add a feature of no strict type checking if
possible and controled with compiler directive.
regards
ml
----------------------------------------------------------------------
This mail sent through Horde-Toaster (http://qmailtoaster.clikka.com/)
More information about the fpc-pascal
mailing list