• sas (cs)

    Now how could you continually leak EvtLogObj objects with zero lines? [|-)]

  • drew (cs) in reply to sas

    looks like yet another example of copy&paste coding. We have all seen it.

    Quick note on an minor internal wtf, almost a wth really (what-the-heck)... could the main page wft entries be set to a width as a percentage so it will wrap a bit? Currently, even on my 1280x1024 monitor, i must scroll right to read the posts. Cheers, drew..

  • (unregistered)

    [li]  Hmmm...  Lets just create objects so we can dispose of them.!  WTF

  • (unregistered) in reply to drew
    drew:

    looks like yet another example of copy&paste coding. We have all seen it.



    You mean rape & paste coding.

  • (unregistered)

    Well... its' quite possible the constructor has some side-effects such as starting a timer and/or opening a file and/or "logging" something.  Notice the "Log" part of the class' name.

    And then the destructor will stop the timer and/or close that file, etc.

    There you go, he could very well be seeing how long it takes to create and destroy an object.

    At least you can do that in "serious" programming languages.  Can't you do the same in VB?

    My $0.02

    Pato

  • (unregistered)

    What is the issue with this?  Obviously there is some action that occurs in the constructor of EVTLOGLib.EvtLogObj, so that is why the object is created and then immediately destroyed.

    And you have to check if ief is Nothing before setting it to Nothing because it is bad programming practice to set a variable to Nothing unnecessarily if it is already Nothing.

    COME ON PEOPLE!

  • brill (cs)
    Alex Papadimoulis:

    If ief Is Nothing Then 
    Set ief = New EVTLOGLib.EvtLogObj
    End If
    If Not ief Is Nothing Then
    Set ief = Nothing
    End If



    It looks like is was supposed to be a boolean switch. e.g.
    result = !result;

    However even if that was the intent, it certainly doesn't do that! and is most certainly a WTF worth the effort of posting.




  • Blue (cs) in reply to sas
    sas:
    Now how could you continually leak EvtLogObj objects with zero lines? [|-)]
  • Blue (cs) in reply to Blue

    Argh.  Quoting.  Must. Quit.  Trying.

    I don't believe there is a leak here - as long as it's .NET - I don't know how VB6 works.  In .NET, it has garbage collection similar to Java.  Once you set ief to nothing, if no other variables reference the object, the GC will clean it up (when it feels like doing so)




  • skicow (cs) in reply to

    :
    Well... its' quite possible the constructor has some side-effects such as starting a timer and/or opening a file and/or "logging" something.  Notice the "Log" part of the class' name.

    And then the destructor will stop the timer and/or close that file, etc.

    Pato

    That's a good guess, but that would still be bad coding. If that was the case then the programmer should have made the 'side-effects' a shared method of the class so he could call the 'side-effects' without having to instantiate a new object.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    My guess for this WTF is cut & paste.

  • (unregistered)

    That's actually very funny.  I bet there was something in-between that was deleted at some point, and was afraid to delete the instantiation and destruction. 

    <FONT style="BACKGROUND-COLOR: #efefef">I remember when I worked with vb6, and I remember hating every single line I had to write.. now reading it.. that's a different type of brain cell murder by stupidity.   </FONT>

  • skicow (cs) in reply to Blue

    Blue:
    Argh.  Quoting.  Must. Quit.  Trying.

    I don't believe there is a leak here - as long as it's .NET - I don't know how VB6 works.  In .NET, it has garbage collection similar to Java.  Once you set ief to nothing, if no other variables reference the object, the GC will clean it up (when it feels like doing so)

    Pretty sure that this is not .NET...'Set' is not used in .NET.

  • (unregistered)
    Alex Papadimoulis:

    This code (from Mike Bates' colleague) achieves in six lines what would take most of us zero.


    Zero isn't quite right - if ief has a value before encountering the 6 lines it'll end up being set to Nothing.
  • David Crowell (cs)

    That is obviously "classic" VB, not VB.NET.  If EvtLogObj is written in VB it will have a Class_Initialize, and Class_Terminate that will be called.  Nothing will leak as VB6 and before used COM reference counting.  We don't know what side effect this code has, but this is a truly great wtf  :)

     

  • (unregistered)

    OK, I don't know much about VB, but assuming there is a desirable side-effect of creating this object, couldn't he/she just do this:

    <font face="Courier New">Set</font>
    <font face="Courier New"> ief = New EVTLOGLib.EvtLogObj
    Set ief = Nothing

    </font>?

    PS: What a hideous Reply widget... thing.  Office 2003 in my brand new Firefox browser - ugh!

  • (unregistered) in reply to Blue

    Blue:

    ...the GC will clean it up (when it feels like doing so)...

    Just to add to this, MSDN says, "Garbage collection happens automatically when a request for memory cannot be satisfied using available free memory."

  • (unregistered)

    My first thought was that he was trying to toggle the EvtLogObj...
    ie
    if ief is nothing 
        Create it
    else
        Destroy it
      
    so you could turn logging on or off with this...

    maybe he just wasnt thinking straight and forgot (or didnt understand) the else...

  • Guayo (cs) in reply to
    :

    [image] Blue wrote:

    ...the GC will clean it up (when it feels like doing so)...

    Just to add to this, MSDN says, "Garbage collection happens automatically when a request for memory cannot be satisfied using available free memory."

    Garbage collects does not happens only when isn't free memory to satisfy a memory request, it's quite more complex than that...
    I think a good way to describe when the GC collects memory is what Blue wrote: “when it feels like doing so”

  • Blue (cs) in reply to

    Re: Just to add to this, MSDN says, "Garbage collection happens automatically when a request for memory cannot be satisfied using available free memory."

    While this may be true, I think it's only true if the process requesting memory is a .NET program --  Other non-.NET software running won't trigger GC during memory requests.   I could be wrong about this, though.


  • (unregistered)

    I for one would achieve the same in exactly one line, but maybe I'm just not Zen enough...

  • (unregistered) in reply to

    If you understand, things are just as they are; if you do not understand, things are just as they are. --Zen proverb

  • cjs (cs) in reply to drew
    drew:

    looks like yet another example of copy&paste coding. We have all seen it.


    Sort of a tangent here, but I've seen some bits of code similar to this that were the result not of cut-and-paste but of automated refactoring tools. Often after an automated refactoring programmers don't examine all of the changed code in context (after all, avoiding that is part of the point of automated refactoring tools), and after two or three refactorings touching a certain area, the code starts to look a little strange, with statements that don't do anything sensible (any more).

  • Drak (cs) in reply to

    :
    Well... its' quite possible the constructor has some side-effects such as starting a timer and/or opening a file and/or "logging" something.  Notice the "Log" part of the class' name.

    And then the destructor will stop the timer and/or close that file, etc.

    There you go, he could very well be seeing how long it takes to create and destroy an object.

    At least you can do that in "serious" programming languages.  Can't you do the same in VB?

    My $0.02

    Pato

    This is immediately what came to my mind as well... Does VB6 support 'shared' functions and subs, other than in a 'module' ?

    Drak

  • (unregistered) in reply to

    :
    OK, I don't know much about VB, but assuming there is a desirable side-effect of creating this object, couldn't he/she just do this:

    <FONT face="Courier New">Set</FONT>
    <FONT face="Courier New"> ief = New EVTLOGLib.EvtLogObj
    Set ief = Nothing

    </FONT>?

    No, the original code doesn't create a new object when it's already set.

  • Katja (cs) in reply to

    Maybe he could just call:

    <font face="Courier New">New EVTLOGLib.EvtLogObj

    instead. That would create the object but since it's not assigned to anything, it gets cleaned up immediately afterwards.

    Still, the original code isn't a real WTF. The first three lines will create an object if it doesn't exist already. If it does exist, it is likely that it has been used for something else too. If not, well... The constructor might create some log file where events are written to. And this file would be empty if the object hasn't been used somewhere else.

    The next three lines are there to clean it up again.

    And probably there has been some code between the first three lines and the last three lines that might have added a bit more to this event log, but later on they could have been removed again.
    </font>

  • Bellinghman (cs) in reply to
    Just some guy:
    No, the original code doesn't create a new object when it's already set.

    However, the second if/endif pair are unnecessary.

  • matejcik (cs) in reply to Bellinghman

    how about this?
    two guys were working on this one. and it was decided that ief will be Nothing after a certain part. however, for some reason, they were afraid to assign it Nothing when it was Nothing already. so, each of them wrote their own solution.
    the first of them created the object if none was there, so as to make the ief=Nothing line "safe".
    and the second checked for ief being nothing before assigning.
    then they commited their changes, and voila :)

  • Katja (cs) in reply to Bellinghman

    Is the second If-Then really unnecessary? I don't think so. What if he has used "on error resume next"? Then if the constructor fails to create a new object, the variable would still be set to Nothing. Thus he avoids replacing nothing by nothing by checking for nothing. Nothing bad about it. [:$]

    Okay, I'm kidding. He could just always assign "Nothing" to the variable. It is contains nothing already then it won't have any effects. Otherwise, the Garbage Collector can do it's work...

  • (unregistered)

    It could be of use if you always wanted the EVTLOGLib.EvtLogObj destructor to be called. Sounds like a nasty way of ensuring a log entry??

  • (unregistered)

    I personally on a daily basis create objects around me then immediately destroy them.  For example, just this morning I framed out a door for my finished basement; not liking the result, I took a sledge hammer to the final result and behold, nothing is left.

    The abililty to put something together and basically render it to oblivion traces back to my childhood when I would put together blocks in nice lilttle towers and buildings and my F*@&&#ing brothers would trash it on me.

    I'm picking up my Prozac today after going unfilled for nearly 6 months.

  • Katja (cs) in reply to

    Lol, your F*@&&#ing brothers turned in a bad email addres that you can click on to send an email... [:D][;)]

  • cicorias (cs) in reply to Katja

    Must be the @ sign....

     

  • F8less (cs)

    Just the fact that a whole forum of people can't figure out what the programmer intended by this piece of code is a WTF in itself. Self documenting code is a very good practice imho.

  • Manni (cs) in reply to Katja

    I tried to write something for a web-based system that would recognize web addresses based on the domain type (.net, .com, etc) and would automatically make a hyperlink out of them. Unfortunately people frequently type out "Visual Studio.NET" which would give them a link to studio.NET.

    That's really all I had to offer for this particular WTF. Nothing even remotely relevant to the topic, but if I were forced at gunpoint to come up with a comment relating to that code, I'd say that the person was dumb. Dumb dumb dumb. Now please put the gun away.

  • Jesse Squire (cs) in reply to Blue

    Blue wrote:
    Once you set ief to nothing, if no other variables reference the object, the GC will clean it up

    Actually, that isn't correct.  The garbage collector will reclaim the object after it goes out of scope.  It has nothing at all to do with setting the reference to null, and doing so can actually extend the life of an object.  Take a peek at this entry[^] from Chris Lyon's blog for more information.

  • Bustaz Kool (cs) in reply to F8less

    F8less:
    Self documenting code is a very good practice imho.

    I'll let you know when I see some.

  • (unregistered) in reply to Jesse Squire
    Jesse Squire:
    Blue wrote:
    The garbage collector will reclaim the object after it goes out of scope.  It has nothing at all to do with setting the reference to null, and doing so can actually extend the life of an object.  Take a peek at this entry[^] from Chris Lyon's blog for more information.


    I am unable to find anything in that blog entry that says doing this will extend the life of an object.  Can you explain how that is possible?

  • Blue (cs) in reply to Jesse Squire

    The first two lines of the blog you referenced:

    "GC Myth: setting an object's reference to null will force the GC to collect it right away.
    GC Truth: setting an object's reference to null will sometimes allow the GC to collect it sooner."


    Yes, it would extend the life of the object if compiled in release mode.   It would stay around until scope is exited rather than optimized by the compiler to be removed after the last statement that uses it executes.   I think this is moot since garbage collection isn't instant anyways.






  • Blue (cs) in reply to Blue

    Correction to previous post, since I can't edit it:

    If Compiled in DEBUG mode, not Release.

  • Bellinghman (cs) in reply to
    :
    [image] Jesse Squire wrote:
    Blue wrote:
    The garbage collector will reclaim the object after it goes out of scope.  It has nothing at all to do with setting the reference to null, and doing so can actually extend the life of an object.  Take a peek at this entry[^] from Chris Lyon's blog for more information.



    I am unable to find anything in that blog entry that says doing this will extend the life of an object.  Can you explain how that is possible?

    He's saying that, for this code

    <FONT color=#ff1493 size=2>  1: obj.DoSomething()
      2:
      3:
    ...      Noting in here mentions obj


    299: obj = Nothing
    300: ... exit scope
    </FONT>

    a) if line 299 isn't there, the optimiser may note that because nothing refers to obj after line 1, it may release it at the beginning of line 2.

    a) But is line 299 is there, the optimiser isn't quite clever enough to notice that the only effect of the line is to release it, and because obj is now mentioned after line 1, it is not released until line 299 explicitly does so.

  • Jesse Squire (cs) in reply to Blue

    Blue wrote:
    Yes, it would extend the life of the object if compiled in release mode.

    Blue wrote:
    I think this is moot since garbage collection isn't instant anyways.

    True and True.  You're not going to see a meaningful performance difference either way, as garbage collection will continue to happen in its own good time.  My point was simply that setting an object to null will not trigger the garbage collector nor shorten an object's lifespan.  If the instruction will be optimized out anyway, why advocate cluttering the code with it?  All it does is add clutter and, perhaps, add confusion for those not as experienced with garbage collection.

    The semantics of your original post led me to believe that you felt it was a necessity to null the reference.  My intention was to help.  I apologize if that was not the case.

  • Jesse Squire (cs) in reply to Jesse Squire
    																Correction to the quote in the previous post, since I can't edit it.&nbsp; Blue's quote should refer to <i>Debugvmode only</i>, not <i>Release</i> mode.&nbsp; Sorry about that.<br>
    
  • (unregistered) in reply to
    :
    OK, I don't know much about VB, but assuming there is a desirable side-effect of creating this object, couldn't he/she just do this:

    <font face="Courier New">Set</font>
    <font face="Courier New"> ief = New EVTLOGLib.EvtLogObj
    Set ief = Nothing
    </font>


    except that you need to check if the object exists which supposedly 'wtf' code does.
  • Blue (cs) in reply to Jesse Squire
    Jesse Squire:
    																Correction to the quote in the previous post, since I can't edit it.&nbsp; Blue's quote should refer to <i>Debugvmode only</i>, not <i>Release</i> mode.&nbsp; Sorry about that.<br>
    


    I self-corrected immediately after my misquote.  :P

  • Blue (cs) in reply to Jesse Squire

    Jesse: re " The semantics of your original post led me to believe that you felt it was a necessity to null the reference.  My intention was to help.  I apologize if that was not the case."

    No worries.  My semantics may have been a bit off - I was only trying to point out that there was no leak in the original WTF.


  • (unregistered) in reply to Guayo

    <FONT style="BACKGROUND-COLOR: #efefef">ditto on "when it feels like doing so", the .net garbage collector is non-deterministic. However if you want you can help yourself by calling gc.collect().  This will help you in the event that the gc's algorythm has decide (based on past calls) that gc won't be needed for a while, you can tell it, "I just did something that will need gc'ing, so do it"  But the gc won't necessarily run at that instant.</FONT>

  • (unregistered)
    <FONT color=#000000>2 lines</FONT>
    If ief Is Nothing Then Set ief = New EVTLOGLib.EvtLogObj 
    

    Set ief = Nothing

     
     
  • foxyshadis (cs) in reply to Katja
    Katja:
    Lol, your F*@&&#ing brothers turned in a bad email addres that you can click on to send an email... Big SmileWink
  • Katja (cs) in reply to foxyshadis
    foxyshadis:
    [image] Katja wrote:
    Lol, your F*@&&#ing brothers turned in a bad email addres that you can click on to send an email... Big SmileWink

    I know you wanted to say something... You're using Mozilla, right? [6]

  • Free (cs) in reply to Blue

    Blue:

    Yes, it would extend the life of the object if compiled in release mode. 

    Yes, in a release build, setting something to null/Nothing will mean just that much longer before it will be collected.

    In a debug build, for the sake of debugging, stuff won't get collected at the first possible chance ( after it is last used).
    In a function, it will stick around until you exit the function.
    So setting an object to null at the end of the function changes nothing.

    In a release build, there is no need to keep anything around for the sake of debugging, as soon as the last reference to your variable is used, it can be collected. If the last reference to your var is setting it to null, then that is one more statement before it can be collected.

    When it actualy gets collected is the other longer story

     

     

     

     

Leave a comment on “Zen and the Art of Programming”

Log In or post as a guest

Replying to comment #:

« Return to Article