Re: [fpc-devel] building pdf documentation
Michael Van Canneyt het geskryf: I don't understand why you have so many problems. I did a standard ubuntu install, installed all of latex (there is a metapackage), and the docs compiled without a single glitch. I couldn't find any 'latex' metapackage. Anyway, I google'd the issue which I thought was a missing font. The packages search website of ubuntu did not reveal anything. I then google'd some more and eventually found a website mentioning the same problem and luckily with a solution as well. It was indeed missing fonts located in the following Ubuntu package: texlive-fonts-recommended I can now successfully 'make ref.pdf' at last! Thanks Michael, Marco and Jonas for all all your input. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] building pdf documentation
On Thu, 10 Sep 2009, Graeme Geldenhuys wrote: Michael Van Canneyt het geskryf: I don't understand why you have so many problems. I did a standard ubuntu install, installed all of latex (there is a metapackage), and the docs compiled without a single glitch. I couldn't find any 'latex' metapackage. Anyway, I google'd the issue which I thought was a missing font. The packages search website of ubuntu did not reveal anything. I then google'd some more and eventually found a website mentioning the same problem and luckily with a solution as well. It was indeed missing fonts located in the following Ubuntu package: texlive-fonts-recommended The package that contains all is called texlive-full. I can now successfully 'make ref.pdf' at last! Thanks Michael, Marco and Jonas for all all your input. Glad that you could do it, now you can start doing real work :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is lnet compilation working?
Fixed, thanks for reporting. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] comparing methods
Hi,
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
For example:
a:=TMyClass.Create;
b:=TMyClass.Create;
if @a.test = @b.test then writeln('the same method');
This results in strange behaviors, when using the following code (from
the FCL):
property AfterConnect: TNotifyEvent read FAfterConnect write SetAfterConnect;
procedure TCustomConnection.SetAfterConnect(const AValue: TNotifyEvent);
begin
if FAfterConnect=AValue then exit;
FAfterConnect:=AValue;
end;
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Mattias Gärtner wrote:
Hi,
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
For example:
a:=TMyClass.Create;
b:=TMyClass.Create;
if @a.test = @b.test then writeln('the same method');
This results in strange behaviors, when using the following code (from
the FCL):
property AfterConnect: TNotifyEvent read FAfterConnect write
SetAfterConnect;
procedure TCustomConnection.SetAfterConnect(const AValue: TNotifyEvent);
begin
if FAfterConnect=AValue then exit;
FAfterConnect:=AValue;
end;
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The deep copy versus shallow copy problem.
Depending on what you want. here it is implementing a deep compare, (an
instance full copy) instead of a shallow compare (a pointer copy). Both
are valid paradigms, but also -very, very - basic computer science. You
for some reason want a shallow compare, which may or may not be correct,
depending on your code.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Michael Schnell mschn...@lumino.de: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
On 10 Sep 2009, at 14:01, Mattias Gärtner wrote: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. The current behaviour has been there since svn revision 1, so it's quite old and established at least (and Delphi/TP-compatible, afaik). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Mattias Gärtner wrote: Zitat von Michael Schnell mschn...@lumino.de: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. Nope, it is: although there is some vmt work involved : the data part is for the new instance, not the global instance. Assigning a new method to one of the two instances your example gives makes them unequal because the instances are deep copies or rather new instances of the same class with different addresses. Hopes that helps. If you assign to an empty variable, like var a,b:TMyClass; begin b:= TMyClass.Create; a:=b; end; You will get the result you expect. Again, very basic. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Jonas Maebe schreef: On 10 Sep 2009, at 14:01, Mattias Gärtner wrote: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. The current behaviour has been there since svn revision 1, so it's quite old and established at least (and Delphi/TP-compatible, afaik). It is delphi compatible, not really intuitive, so I would welcome a change in the objfpc mode. See: http://bugs.freepascal.org/view.php?id=9228 http://bugs.freepascal.org/view.php?id=11868 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] documentation: chart.[ps|pdf]
Hi, I downloaded a while back the FPC 2.2.0 and 2.2.4 documentation in PDF and PS format. In both cases the chart.* files were incorrect (I believe). The filename implies a chart, so I gathered that it is a class chart / hierarchy of some kind. But when I view it, it is just a listing of the local compiler switches. Is this correct? In that case, I don't understand the logic behind the filename chart.xxx Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] documentation: chart.[ps|pdf]
On Thu, 10 Sep 2009, Graeme Geldenhuys wrote: Hi, I downloaded a while back the FPC 2.2.0 and 2.2.4 documentation in PDF and PS format. In both cases the chart.* files were incorrect (I believe). The filename implies a chart, so I gathered that it is a class chart / hierarchy of some kind. But when I view it, it is just a listing of the local compiler switches. Is this correct? In that case, I don't understand the logic behind the filename chart.xxx If you have a suggestion, I'll be glad to change the name. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] documentation: chart.[ps|pdf]
Michael Van Canneyt het geskryf: If you have a suggestion, I'll be glad to change the name. So the name and content is correct? Umm, so how did you get to the name chart? :-) When I opened that file, I expected the class hierarchy chart - you know, like the one Borland gave with D7 K3. Umm, name suggestions (something I suck at): compiler_switches.xxx ??? and for those poor folks with DOS 1.0, maybe: comp_swh.xxx I much rather prefer the first option though. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] documentation: chart.[ps|pdf]
Graeme Geldenhuys schreef: Michael Van Canneyt het geskryf: If you have a suggestion, I'll be glad to change the name. So the name and content is correct? Umm, so how did you get to the name chart? :-) When I opened that file, I expected the class hierarchy chart - you know, like the one Borland gave with D7 K3. It is the compiler switches quick reference chart. Or maybe better compiler switches quick reference card. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Thaddy tha...@thaddy.com: Mattias Gärtner wrote: Zitat von Michael Schnell mschn...@lumino.de: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. Nope, it is: although there is some vmt work involved : the data part is for the new instance, not the global instance. Assigning a new method to one of the two instances your example gives makes them unequal because the instances are deep copies or rather new instances of the same class with different addresses. Hopes that helps. Not at all. But thanks for trying. If you assign to an empty variable, like var a,b:TMyClass; begin b:= TMyClass.Create; a:=b; end; You will get the result you expect. The 'a,b' above are pointers to mem areas. a=b compares the pointers. If a,b would be records then a=b would compare the mem. If a,b would be 'procedure of object' then a=b compares only half of the mem. This is different to both cases above. Hope this helps. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Jonas Maebe jonas.ma...@elis.ugent.be: On 10 Sep 2009, at 14:01, Mattias Gärtner wrote: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. The current behaviour has been there since svn revision 1, so it's quite old and established at least (and Delphi/TP-compatible, afaik). Yes, and since the beginning I was wondering why. Years ago I thought, there are probably cases where this is useful. But since today I hardly saw one. OTOH I saw several times code that misused it. If it is only for delphi/tp compatibility, then maybe it can be changed in mode objfpc? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] documentation: chart.[ps|pdf]
Vincent Snijders het geskryf: It is the compiler switches quick reference chart. Or maybe better compiler switches quick reference card. Ah, like the ones in the Dummies guide of ... books. :-) Then maybe quickref.xxx is a better name than chart.xxx - that's if we limit ourselves to 8.3 names (80's style). Alternatively: fpc_quick_reference_card.xxx Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] document header mistakes
On Thu, 10 Sep 2009, Graeme Geldenhuys wrote: Hi Michael, I'm not picking on you, I promise! :-) I'm just doing my bit evaluating the upcoming FPC 2.4 release - code docs. Too late, the intercontinental ballistic missile has left ---[ ref.xxx ]--- 1) In the current ref.ps ref.pdf documents, page 6 doesn't contain a header, where all pages before and after it has got headers (which contains the section title). 2) Page 7 actually contains page 6's header. List of Tables. I think page 7 should not have a header, or maybe About this Guide? I'm not sure I can fix those, this is a latex issue; maybe an additional pass will fix it. ---[ prog.xxx ]--- 1) Same problem as number 2 above. Page 11 seems to have the wrong header title. 2) Also the section number is a bit odd. 0.1 - but that's not really a biggy. Maybe the section number could be left out like was done in the ref.xxx document. It's all about consistency. ;-) I'll have a look at this. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Vincent Snijders vsnijd...@vodafonevast.nl: Jonas Maebe schreef: On 10 Sep 2009, at 14:01, Mattias Gärtner wrote: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. The current behaviour has been there since svn revision 1, so it's quite old and established at least (and Delphi/TP-compatible, afaik). It is delphi compatible, not really intuitive, so I would welcome a change in the objfpc mode. See: http://bugs.freepascal.org/view.php?id=9228 http://bugs.freepascal.org/view.php?id=11868 To draw the whole picture: var a,b: TNotifyEvent; a=b compares only Code, not Data a=nil compares only Data, not Code Assigned(a) compares only Code, not Data n.a.compares both I wonder how many programmers know this. Even the FCL contains code, where this leads to wrong code. More important: I don't know a place, where a=b and a=nil are used right. But I have seen a lot of code where it was used wrong. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
I have done some horrible code where I needed to know the following: If TSomeProc = procedure(), then is it easy to determine or set entry vector of ThatProc: TSomeProc by stating ThatProc := @ProcWhereTheCodeLives_InTheCodeSegment; It gets more difficult when you work with TSomeClassProc = procedure() of object, because two parts are referenced here: 1) The entry vector where the code lives, 2) The heap address where the object struct lives. (Known as the Self variable in a procedure of object) I have worked out which pointer of the two pointers belongs to the code and which to the instance with a trial. With a move operation, I was able to manipulate the two pointers, specifically to determine the address of the instance. The @ operator only gives you access to the procedure part. Is there, or will there be, another operator to give you access to the instance address? 2009/9/10 Mattias Gärtner nc-gaert...@netcologne.de Zitat von Vincent Snijders vsnijd...@vodafonevast.nl: Jonas Maebe schreef: On 10 Sep 2009, at 14:01, Mattias Gärtner wrote: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. The current behaviour has been there since svn revision 1, so it's quite old and established at least (and Delphi/TP-compatible, afaik). It is delphi compatible, not really intuitive, so I would welcome a change in the objfpc mode. See: http://bugs.freepascal.org/view.php?id=9228 http://bugs.freepascal.org/view.php?id=11868 To draw the whole picture: var a,b: TNotifyEvent; a=b compares only Code, not Data a=nil compares only Data, not Code Assigned(a) compares only Code, not Data n.a.compares both I wonder how many programmers know this. Even the FCL contains code, where this leads to wrong code. More important: I don't know a place, where a=b and a=nil are used right. But I have seen a lot of code where it was used wrong. Mattias ___ 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] document header mistakes
In our previous episode, Michael Van Canneyt said: 2) Also the section number is a bit odd. 0.1 - but that's not really a biggy. Maybe the section number could be left out like was done in the ref.xxx document. It's all about consistency. ;-) I'll have a look at this. Note that the HTML relinking abuses this fact iirc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
On Thu, 10 Sep 2009 14:25:26 +, Desmond Coertzen
patrolliekapt...@gmail.com wrote:
I have done some horrible code where I needed to know the following:
If TSomeProc = procedure(), then is it easy to determine or set
entry
vector of ThatProc: TSomeProc by stating ThatProc :=
@ProcWhereTheCodeLives_InTheCodeSegment;
It gets more difficult when you work with TSomeClassProc =
procedure()
of object, because two parts are referenced here: 1) The entry vector
where
the code lives, 2) The heap address where the object struct lives.
(Known
as
the Self variable in a procedure of object)
I have worked out which pointer of the two pointers belongs to the code
and
which to the instance with a trial. With a move operation, I was able to
manipulate the two pointers, specifically to determine the address of
the
instance.
The @ operator only gives you access to the procedure part. Is there, or
will there be, another operator to give you access to the instance
address?
You can use the TMethod record to access the fields:
{$mode objfpc}
type
tc=class
procedure p;
end;
procedure tc.p;
begin
end;
var
c : tc;
begin
writeln(hexstr(tmethod(@c.p).data));
writeln(hexstr(tmethod(@c.p).code));
c:=tc.create;
writeln(hexstr(tmethod(@c.p).data));
writeln(hexstr(tmethod(@c.p).code));
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Thank you Peter.
TMethod would have been handy if i knew about this back then. For delphi
compatibility, I had to do this:
program methodpointer;
uses
Classes, sysutils;
type
TMyEvent = procedure of object;
TMyClass = class(TObject)
procedure MyMethod;
end;
{ TMyClass }
procedure TMyClass.MyMethod;
begin
end;
var
MyEvent : TMyEvent;
Addr: ^TMethod;
MyClass: TMyClass = nil;
begin
writeln(hexStr(TMethod(TMyEvent(MyClass.MyMethod)).Code));
writeln(hexStr(TMethod(TMyEvent(MyClass.MyMethod)).Data));
MyClass := TMyClass.Create;
writeln(hexStr(TMethod(TMyEvent(MyClass.MyMethod)).Code));
writeln(hexStr(TMethod(TMyEvent(MyClass.MyMethod)).Data));
FreeAndNil(MyClass);
end.
On Thu, Sep 10, 2009 at 2:56 PM, Peter Vreman pe...@cooldown.xs4all.nlwrote:
On Thu, 10 Sep 2009 14:25:26 +, Desmond Coertzen
patrolliekapt...@gmail.com wrote:
I have done some horrible code where I needed to know the following:
If TSomeProc = procedure(), then is it easy to determine or set
entry
vector of ThatProc: TSomeProc by stating ThatProc :=
@ProcWhereTheCodeLives_InTheCodeSegment;
It gets more difficult when you work with TSomeClassProc =
procedure()
of object, because two parts are referenced here: 1) The entry vector
where
the code lives, 2) The heap address where the object struct lives.
(Known
as
the Self variable in a procedure of object)
I have worked out which pointer of the two pointers belongs to the code
and
which to the instance with a trial. With a move operation, I was able to
manipulate the two pointers, specifically to determine the address of
the
instance.
The @ operator only gives you access to the procedure part. Is there, or
will there be, another operator to give you access to the instance
address?
You can use the TMethod record to access the fields:
{$mode objfpc}
type
tc=class
procedure p;
end;
procedure tc.p;
begin
end;
var
c : tc;
begin
writeln(hexstr(tmethod(@c.p).data));
writeln(hexstr(tmethod(@c.p).code));
c:=tc.create;
writeln(hexstr(tmethod(@c.p).data));
writeln(hexstr(tmethod(@c.p).code));
end.
___
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] comparing methods
Ivo Steinmann schrieb: 1. Using =nil or Assigned should result in the same. Afaik not, this was one of the reasons for assigned. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Mattias Gärtner wrote: Zitat von Michael Schnell mschn...@lumino.de: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case code address, the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than address of. Most interesting. I also always sought @Instance.Method, returns a TMethod record (that is the address of the instance and the address of the Code). But mor interesting: There a various mails/requests about: - overloading by result - automatic extending a calculation to the type of the result AInteger := AByte + AByte can cause an overflow, even though the result would have enough space Every time the answer includes something like: The evaluation of an expression (rvalue) is done independent of the type of the variable to which it will be assigned (lvalue) . A statement I do agree with 100%. Therefore in Int := Byte + Byte the rvalue is calculated using bytes. And therefore an overload by result is not possible as when evaluating what to call, the type of the lvalue is unknown. And now I am reading this mail, and unless I misunderstood something: The result of @Instance.Method depends on the lvalue's type or the context? (assignment vs compare). That seems to be in direct disagreement to the above statement? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
On Thu, 10 Sep 2009 17:52:44 +0200 Florian Klaempfl flor...@freepascal.org wrote: Ivo Steinmann schrieb: 1. Using =nil or Assigned should result in the same. Afaik not, this was one of the reasons for assigned. Are there any other reasons for assigned? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Mattias Gaertner schrieb: On Thu, 10 Sep 2009 17:52:44 +0200 Florian Klaempfl flor...@freepascal.org wrote: Ivo Steinmann schrieb: 1. Using =nil or Assigned should result in the same. Afaik not, this was one of the reasons for assigned. Are there any other reasons for assigned? Distinction between f=nil and f=nil ;)? When it was introduced, I guess f()=nil was not possible. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
On Thu, 10 Sep 2009, Florian Klaempfl wrote: Mattias Gaertner schrieb: On Thu, 10 Sep 2009 17:52:44 +0200 Florian Klaempfl flor...@freepascal.org wrote: Ivo Steinmann schrieb: 1. Using =nil or Assigned should result in the same. Afaik not, this was one of the reasons for assigned. Are there any other reasons for assigned? Distinction between f=nil and f=nil ;)? When it was introduced, I guess f()=nil was not possible. Another idea was that Assigned() could test if a pointer was within range of the heap. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Florian Klaempfl schrieb: Ivo Steinmann schrieb: 1. Using =nil or Assigned should result in the same. Afaik not, this was one of the reasons for assigned. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel well, nobody seems to know it... eg. if you go through code in rtl (classes, etc...) sometimes =nil is used, sometimes Assigned. it's a complete random mix. I don't think that this mix was intention. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Michael Van Canneyt wrote: On Thu, 10 Sep 2009, Florian Klaempfl wrote: Mattias Gaertner schrieb: On Thu, 10 Sep 2009 17:52:44 +0200 Florian Klaempfl flor...@freepascal.org wrote: Ivo Steinmann schrieb: 1. Using =nil or Assigned should result in the same. Afaik not, this was one of the reasons for assigned. Are there any other reasons for assigned? Distinction between f=nil and f=nil ;)? When it was introduced, I guess f()=nil was not possible. Another idea was that Assigned() could test if a pointer was within range of the heap. To my knowledge, in Delphi Assigned() tests only the high-order word of the pointer, thus returning False for everything below 64k. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
