Hey, thanks for all the help. Now it's clear.
Hey, thanks for all the help. Now it's clear.
I have the exact same thingOriginally Posted by WILL
I have not looked under the hood, so could you clarify why is does a VMT look up when no methods are involved. is only checks if a class is of a certain type, which seems to be to be a RTTI issue rather than a VMT issue, but maybe I'm overlooking something here.Originally Posted by dmantione
Every class created carries a pointer to its VMT in its data. Two classes are of the same type if their VMT index is equal. So, to implement "is", the VMT offset is read from the class instance, then compared to the vmt offset of the right hand side. Then the parent VMT is tested, and so on until we reach Tobject.
If that's correct then you are going to check if the pointer is nil anyways before using the "is" operator. Else you risk a heavy AV
Peregrinus, expectavi pedes meos in cymbalis
Nullus norvegicorum sole urinat
I haven't seen anywhere that a object reference is nil when it is not yet created / when it is deleted, altrough in delphi a lot of functions work with this assumption (such as freeandnil) it is not part of any pascal standard / guidelines, so the object <> nil would probably not be "proper" code to check if a object reference is valid or not altrough it "works" under delphi & FPC (and others).
This is my game project - Top Down City:
http://www.pascalgamedevelopment.com...y-Topic-Reboot
My OpenAL audio wrapper with Intelligent Source Manager to use unlimited:
http://www.pascalgamedevelopment.com...source+manager
Oh, I would give $1 million to have those features in C++!!! I've started working for a small gamedev team, and they are using C++. Before this project, I couldn't even imagine what kind of hell can produce single uninitialized variable. God bless Delphe & FPC & all other languages which have automatic initialization to nil/0/false/...
blog: http://alexionne.blogspot.com/
This is not a rule in delphi / fpc, but is done for object references / variables. however, for other normal (i know for local variables using native and other types such as records for sure), it is not initialized to zero.Originally Posted by alexione
This is my game project - Top Down City:
http://www.pascalgamedevelopment.com...y-Topic-Reboot
My OpenAL audio wrapper with Intelligent Source Manager to use unlimited:
http://www.pascalgamedevelopment.com...source+manager
Does it mean it is a better practice to place if's inside other if's, instead of using parenthesis? In example, this...Originally Posted by dmantione
... is better than...Code:if a = b then if b = c then WriteLn('a = c!!');
Code:if (a = b) and (b = c) then WriteLn('a = c!!');
Of course not, in this case the parentheses reduce the amount of code, and thus readability and speed. I never said they are evil
When I wrote that I was thinking of code like:
[pascal]
else if (rd.typ=stringdef) or
(ld.typ=stringdef) or
((is_pchar(rd) or is_chararray(rd) or is_char(rd) or is_open_chararray(rd) or
is_pwidechar(rd) or is_widechararray(rd) or is_widechar(rd) or is_open_widechararray(rd)) and
(is_pchar(ld) or is_chararray(ld) or is_char(ld) or is_open_chararray(ld) or
is_pwidechar(ld) or is_widechararray(ld) or is_widechar(ld) or is_open_widechararray(ld))) then
[/pascal]
(citation from FPC source). When you are working with code like this the parentheses, especially if, while editing, they get wrong indentation or end up on the wrong line, it can become a time consuming puzzle to get your expression right.
Bookmarks