Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31

Thread: "is" versus "<> nil" on speed?

  1. #11

    "is" versus "<> nil" on speed?

    Hey, thanks for all the help. Now it's clear.

  2. #12

    "is" versus "<> nil" on speed?

    Quote Originally Posted by WILL
    Funny, I often find the parenthesis makes it easy for me to read the code.
    I have the exact same thing

  3. #13

    "is" versus "<> nil" on speed?

    Quote Originally Posted by dmantione
    The difference is subtle, but "is" is implemented by analysing the virtual method tables, not the runtime type information. So, if you want to avoid RTTI bloat, you can still safely use "is".
    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.
    <br /><br />There are a lot of people who are dead while they are still alive. I want to be alive until the day I die.<br />-= Paulo Coelho =-

  4. #14

    "is" versus "<> nil" on speed?

    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.

  5. #15

    "is" versus "<> nil" on speed?

    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

  6. #16

    "is" versus "<> nil" on speed?

    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

  7. #17

    "is" versus "<> nil" on speed?

    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/

  8. #18

    "is" versus "<> nil" on speed?

    Quote Originally Posted by alexione
    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/...
    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.
    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

  9. #19

    "is" versus "<> nil" on speed?

    Quote Originally Posted by dmantione
    Quote Originally Posted by jasonf
    hmmm... I've been using

    [pascal]if not (obj = nil)[/pascal]

    is this slower than [pascal]if obj <> nil[/pascal] ?
    This is an easy optimization, most compilers will generate the same code for both, including FPC. However, especially in complex bollean expressions, it can be good forr eadibility to remove some parenthesis.
    Does it mean it is a better practice to place if's inside other if's, instead of using parenthesis? In example, this...

    Code:
    if a = b then
      if b = c then WriteLn&#40;'a = c!!'&#41;;
    ... is better than...

    Code:
    if &#40;a = b&#41; and &#40;b = c&#41; then WriteLn&#40;'a = c!!'&#41;;

  10. #20

    "is" versus "<> nil" on speed?

    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.

Page 2 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •