DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 5 FirstFirst 1234 ... LastLast
Results 16 to 30 of 65

Thread: Set MyObject=Nothing?

  1. #16
    Anthony Jones Guest

    Re: Set MyObject=Nothing?

    >>
    It's just that VB doesn't make it easy for novice's to know when they don't
    need to, that's why people tend to recommend doing it all the time.
    <<

    It seems to me that you have two choices here.

    You can instruct a novice programmers to plaster Set obj = nothing
    statements at the end of procedures.

    OR

    You can instruct them in what actually going on so they can make an
    informed choice when to include a Set obj = Nothing.

    I prefer the latter.


    --
    Anthony Jones
    Nuesoft Ltd




  2. #17
    Bob Butler Guest

    Re: Set MyObject=Nothing?

    "Anthony Jones" <yadayadayada@msn.com> wrote in message
    news:39f2ed73$1@news.devx.com...
    > Do you also do the following to all your string variables
    >
    > str = vbNullString
    > at the end of all your procedures?


    No, I don't, but that is a better example than numeric variables.

    > If the latter is true, why would you trust VB call SysFreeString but not
    > trust it to call IUnknown.Release?


    Because strings don't hold references to other objects and the order in
    which strings are released is not important. With objects I want complete
    control over what happens when. I do fully understand that in most cases it
    is superfluous but I still prefer to include it since I find it makes it
    easier to read and maintain.

    There is no right or wrong here and obviously neither side is going to be
    convinced so this thread needs to die.
    Set Thread=Nothing ' <g>




  3. #18
    John Perkins Guest

    Re: Set MyObject=Nothing?


    I agree with you. My post was just to offer one possible explanation of why
    some people make a dogmatic rule of it, i.e., because they don't understand
    it completely.

    -John Perkins


    "Anthony Jones" <yadayadayada@msn.com> wrote:
    >>>

    >It's just that VB doesn't make it easy for novice's to know when they don't
    >need to, that's why people tend to recommend doing it all the time.
    ><<
    >
    >It seems to me that you have two choices here.
    >
    >You can instruct a novice programmers to plaster Set obj = nothing
    >statements at the end of procedures.
    >
    >OR
    >
    >You can instruct them in what actually going on so they can make an
    >informed choice when to include a Set obj = Nothing.
    >
    >I prefer the latter.
    >
    >
    >--
    >Anthony Jones
    >Nuesoft Ltd
    >
    >
    >



  4. #19
    Anthony Jones Guest

    Re: Set MyObject=Nothing?

    Bob,

    I agree. I am unconvinced. :-)

    Can you give an example of when the order in which objects are released is
    important?

    Can you explain why this/these case(s) are significant enough to warrant
    explicit Set obj = nothing statements at the end of all procedures?

    --
    Anthony Jones
    Nuesoft Ltd




  5. #20
    Bob Butler Guest

    Re: Set MyObject=Nothing?

    "Anthony Jones" <yadayadayada@msn.com> wrote in message
    news:39f33e51$1@news.devx.com...
    > Bob,
    >
    > I agree. I am unconvinced. :-)
    >
    > Can you give an example of when the order in which objects are released is
    > important?


    In cases where you have parent/child logical relationships you may want to
    release child objects first. If you look at cases like the ADO model where
    recordsets have references to the connection you need to clean up the
    recordsets in order to be able to release the connection -- I've had similar
    object interrelationships within my own objects where the order I released
    things affected when system resources were gone. I like having that degree
    of control, even if it is not a critical issue.

    > Can you explain why this/these case(s) are significant enough to warrant
    > explicit Set obj = nothing statements at the end of all procedures?


    As I've said, I prefer to explicitly release any/all resources that I
    allocate. That applies to everything, including objects, whether or not the
    default cleanup VB provides would do it for me correctly or not. It allows
    me to move my code more easily to other languages and other versions of the
    same language and makes general maintenance much easier FOR ME. If you do
    not find that to be the case, or if you haven't done enough cross-version
    and cross-language development to have seen the advantages, then by all
    means don't do it.

    Let's turn this around: including the "Set =Nothing" is not strictly
    necessary but, other than making the procedure a few lines longer, what harm
    does it do? VB still checks the references and finds nothing to do so it is
    not going to affect performance adversely. If you don't like them when you
    see code that has them then remove them. When I have to deal with code that
    does not have them I add them. Neither of us will ever convince the other
    because we both understand what is happening and simply disagree on the
    preferred style.




  6. #21
    Michael Culley Guest

    Re: Set MyObject=Nothing?


    Bob,

    >Why? When the module goes out of scope, or the app ends, the references
    >will be released.


    I found odd behaviour here once in a usercontrol when someone using the compiled
    usercontrol in an exe pushed the stop button. I can't remember all the details
    (weak circular reference were invlolved) but once bitten...

    >Yes, it does. I do not argue that.


    In one case I know of VB does not do the default behavoiur if you do it for
    it. eg:

    Sub ABC
    Dim x as long
    Dim y as long
    x=1
    y=x
    end sub

    In this case vb does not initialise x or y to zero because you initialise
    them youself. I thought it may be the same for Set obj=Nothing but VB does
    do it twice.

    >One early DAO version,
    >for example, did not properly release resources if you did not explicitly
    >close recordsets and/or databases.)


    I would never leave a recordset open at the end of function. We had someone
    at work who routinely did this. One day he forgot to put in rs.update. I
    think ado will update when you do a movenext anyway, but the last record
    was not being saved because it never got an update. If there had been a .close
    there he would have got an error to alert him to the problem.

    One question. Do you do the set obj=Nothing in your error handling code also?

    Michael Culley



    "Bob Butler" <butlerbob@earthlink.net> wrote:
    >"Michael Culley" <m_culley@one.net.au> wrote in message
    >news:39f2d315$1@news.devx.com...
    >> A better example would be do you set variables to default values at the

    >start
    >> of functions?

    >
    >That's still not a good example but in most cases if I depend on a specific
    >value being there I do set it, even if it is the default. I've been burned
    >more than once in various languages when default behavior changed and I've
    >learned not to rely on it when I can easily avoid it.
    >
    >> I had a poke around to see what VB does and it seams that it still does

    >the
    >> Set Obj=Nothing itself even if you do it.

    >
    >Yes, it does. I do not argue that. What I do believe is that having the
    >code do it explicitly shows me exactly when and where in my code I no longer
    >need it. It also serves to remind me to call any .Close or other method
    >needed to shut down cleanly. I see a lot of code where people rely on the
    >variable going out of scope and then rely on the termination doing
    >cleanup... I've always held that better to take complete control over the
    >lifetime of any objects you use and the upcoming changes in VB.Net are going
    >to force people to do just that in a lot more cases.
    >
    >The current versions of VB handle it for you and do it properly (at least

    in
    >most cases - I do not know offhand of any objects that do not shut down
    >cleanly now although I have seen them in the past. One early DAO version,
    >for example, did not properly release resources if you did not explicitly
    >close recordsets and/or databases.) If you are comfortable in relying on
    >the VB cleanup now then by all means do so. I always try to code with an
    >eye towards moving to new versions and/or other languages down the line

    so I
    >prefer to be as explicit as possible. For me it has paid off in the past
    >and it looks like it's going to make VB.Net easier to adopt.
    >
    >> There is one case where I use it and that is in terminate events for

    >object
    >> dimmed at the module level.

    >
    >Why? When the module goes out of scope, or the app ends, the references
    >will be released. You don't trust VB to do that correctly somehow? As

    long
    >as you do not have circular references set up it will all be handled
    >automatically...
    >
    >As far as I'm concerned, always releasing references lets you control the
    >order and timing and makes the code more self-documenting.
    >
    >



  7. #22
    Mark Alexander Bertenshaw Guest

    Re: Set MyObject=Nothing?

    "Andy Chevin" <yoshimura.freeserve.co.uk> wrote in message
    news:39f1e100@news.devx.com...

    <snip>

    >
    > It's like setting all numeric vars to zero at the bottom of a routine, but
    > you don't do that (do you?).
    >
    > Andy.


    I suppose the difference is that Set xxxx = Nothing actually makes a hidden
    call to ReleaseRef, and could potentially be freeing memory, as opposed to
    just setting something, which would be thrown off the stack, to zero.

    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    PrimeResponse
    Brentford
    UK



  8. #23
    Mark Alexander Bertenshaw Guest

    Re: Set MyObject=Nothing?

    Bob -

    <snip>

    > I see a lot of code where people rely on the
    > variable going out of scope and then rely on the termination doing
    > cleanup... I've always held that better to take complete control over the
    > lifetime of any objects you use and the upcoming changes in VB.Net are

    going
    > to force people to do just that in a lot more cases.
    >


    Really? I thought that the whole point of the fuss over .NET was that there
    was <no> knowing exactly _when_ the objects would terminate. Thus making
    attempts to "control" this process would be pointless.

    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    PrimeResponse
    Brentford
    UK




  9. #24
    Mark Alexander Bertenshaw Guest

    Re: Set MyObject=Nothing?

    Bob -

    <snip>

    > Let's turn this around: including the "Set =Nothing" is not strictly
    > necessary but, other than making the procedure a few lines longer, what

    harm
    > does it do? VB still checks the references and finds nothing to do so it

    is
    > not going to affect performance adversely. If you don't like them when

    you
    > see code that has them then remove them.
    >


    It's a shame that the VB compiler couldn't optimise out this behaviour <g>.
    It will be interesting to see whether this is what VB.NET will do.

    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    PrimeResponse
    Brentford
    UK



  10. #25
    David Hay Guest

    Re: Set MyObject=Nothing?


    "Bob Butler" <butlerbob@earthlink.net> wrote:
    >I see a lot of code where people rely on the
    >variable going out of scope and then rely on the termination doing
    >cleanup... I've always held that better to take complete control over the
    >lifetime of any objects you use


    Setting an object variable to nothing does not mean you take complete control
    over the lifetime of any objects you use. It simply decreases the object's
    reference count by one. When the reference count gets to 0, VB takes care
    of destroying the object.

    I have seen so many people, including Microsoft courses and books, simply
    state that you need to set object references to nothing to destroy the objects
    and then give examples where object variables dimmed in procedures are set
    to nothing at the end of the procedure, or module level object variables
    are set to nothing in the terminate event. I believe this has lead to the
    belief by many that setting object variables to nothing destroys the object.
    Not enough attention is paid to understanding object lifetime, with the result
    that all too often you see bad coding such as circular references. I still
    see atricles in VBPJ that include circular references without proper cleanup.

    I review a lot of code, and whenever I see a someone always setting variables
    to nothing when they are about to go out of scope I always ask them why and
    find out if they understand form and object lifetime. Bob, you might be
    a first, because I have always found they don't understand.

    >...and the upcoming changes in VB.Net are going
    >to force people to do just that in a lot more cases.


    Bob may be right in that it may make it easier to change existing applications
    if you must do something extra in VB.Net. However, because you are not forced
    to set variables to nothing, while it may be standard practice to do so,
    chances are there are still places where they aren't. You'll still need to
    check over your code pretty carefully.

    Besides, from other stuff I have seen written about VB.Net there are so many
    other significant changes (eg. how interfaces, inheritance, constructors
    etc are implemented) either to keep backwards compatibility there will be
    so may compromises made which will be made for the long term, or we are going
    to have to spend a lot of work changing existing apps.

    >As far as I'm concerned, always releasing references lets you control the
    >order and timing and makes the code more self-documenting.


    Again, because setting object variables to nothing does not in itself destroy
    objects, this does not guarantee the order and timing. If you do have code
    where order and timing is that critical then it sounds like procedural code
    rather than object-oriented.

  11. #26
    David Hay Guest

    Re: Set MyObject=Nothing?


    "Michael Culley" <m_culley@one.net.au> wrote:

    >>Why? When the module goes out of scope, or the app ends, the references
    >>will be released.

    >
    >I found odd behaviour here once in a usercontrol when someone using the

    compiled
    >usercontrol in an exe pushed the stop button. I can't remember all the details
    >(weak circular reference were invlolved) but once bitten...
    >


    I don't think setting object references to nothing in the terminate event
    would help here. When the Stop button is pressed or when Stop or End is
    in encountered in code the application ends immediately without any terminate
    events firing.
    >>Yes, it does. I do not argue that.

    >
    >In one case I know of VB does not do the default behavoiur if you do it

    for
    >it. eg:
    >
    >Sub ABC
    > Dim x as long
    > Dim y as long
    > x=1
    > y=x
    >end sub
    >
    >In this case vb does not initialise x or y to zero because you initialise
    >them youself. I thought it may be the same for Set obj=Nothing but VB does
    >do it twice.
    >
    >>One early DAO version,
    >>for example, did not properly release resources if you did not explicitly
    >>close recordsets and/or databases.)

    >
    >I would never leave a recordset open at the end of function. We had someone
    >at work who routinely did this. One day he forgot to put in rs.update. I
    >think ado will update when you do a movenext anyway, but the last record
    >was not being saved because it never got an update. If there had been a

    .close
    >there he would have got an error to alert him to the problem.
    >
    >One question. Do you do the set obj=Nothing in your error handling code

    also?
    >
    >Michael Culley
    >
    >
    >
    >"Bob Butler" <butlerbob@earthlink.net> wrote:
    >>"Michael Culley" <m_culley@one.net.au> wrote in message
    >>news:39f2d315$1@news.devx.com...
    >>> A better example would be do you set variables to default values at the

    >>start
    >>> of functions?

    >>
    >>That's still not a good example but in most cases if I depend on a specific
    >>value being there I do set it, even if it is the default. I've been burned
    >>more than once in various languages when default behavior changed and I've
    >>learned not to rely on it when I can easily avoid it.
    >>
    >>> I had a poke around to see what VB does and it seams that it still does

    >>the
    >>> Set Obj=Nothing itself even if you do it.

    >>
    >>Yes, it does. I do not argue that. What I do believe is that having the
    >>code do it explicitly shows me exactly when and where in my code I no longer
    >>need it. It also serves to remind me to call any .Close or other method
    >>needed to shut down cleanly. I see a lot of code where people rely on

    the
    >>variable going out of scope and then rely on the termination doing
    >>cleanup... I've always held that better to take complete control over

    the
    >>lifetime of any objects you use and the upcoming changes in VB.Net are

    going
    >>to force people to do just that in a lot more cases.
    >>
    >>The current versions of VB handle it for you and do it properly (at least

    >in
    >>most cases - I do not know offhand of any objects that do not shut down
    >>cleanly now although I have seen them in the past. One early DAO version,
    >>for example, did not properly release resources if you did not explicitly
    >>close recordsets and/or databases.) If you are comfortable in relying

    on
    >>the VB cleanup now then by all means do so. I always try to code with

    an
    >>eye towards moving to new versions and/or other languages down the line

    >so I
    >>prefer to be as explicit as possible. For me it has paid off in the past
    >>and it looks like it's going to make VB.Net easier to adopt.
    >>
    >>> There is one case where I use it and that is in terminate events for

    >>object
    >>> dimmed at the module level.

    >>
    >>Why? When the module goes out of scope, or the app ends, the references
    >>will be released. You don't trust VB to do that correctly somehow? As

    >long
    >>as you do not have circular references set up it will all be handled
    >>automatically...
    >>
    >>As far as I'm concerned, always releasing references lets you control the
    >>order and timing and makes the code more self-documenting.
    >>
    >>

    >



  12. #27
    David Hay Guest

    Re: Set MyObject=Nothing?


    "Bob Butler" <butlerbob@earthlink.net> wrote:
    >"Anthony Jones" <yadayadayada@msn.com> wrote in message
    >news:39f2ed73$1@news.devx.com...
    >> Do you also do the following to all your string variables
    >>
    >> str = vbNullString
    >> at the end of all your procedures?

    >
    >No, I don't, but that is a better example than numeric variables.
    >
    >> If the latter is true, why would you trust VB call SysFreeString but not
    >> trust it to call IUnknown.Release?

    >
    >Because strings don't hold references to other objects and the order in
    >which strings are released is not important. With objects I want complete
    >control over what happens when. I do fully understand that in most cases

    it
    >is superfluous but I still prefer to include it since I find it makes it
    >easier to read and maintain.
    >
    >There is no right or wrong here and obviously neither side is going to be
    >convinced so this thread needs to die.
    >Set Thread=Nothing ' <g>


    Ah!! this illustrates the problem very well. I am still interested in this
    thread and am holding a reference to it. Therefore, just setting Thread
    = Nothing has not destroyed the thread, it has just decremented the reference
    count of Bob's interest in it by one. Only when the last person interested
    in adding to the thread will it actually die. See Bob, setting an object
    reference to Nothing does not give you the complete
    control over what happens when that you want.



  13. #28
    David Hay Guest

    Re: Set MyObject=Nothing?


    "Anthony Jones" <yadayadayada@msn.com> wrote:
    >Bob,
    >
    >I agree. I am unconvinced. :-)
    >
    >Can you give an example of when the order in which objects are released

    is
    >important?


    I agree with Anthony. As I said in a previous post, if the order is important
    then it sounds like procedural code rather than object-oriented.

  14. #29
    David Hay Guest

    Re: Set MyObject=Nothing?


    "Bob Butler" <butlerbob@earthlink.net> wrote:
    >"Anthony Jones" <yadayadayada@msn.com> wrote in message
    >news:39f33e51$1@news.devx.com...
    >> Bob,
    >>
    >> I agree. I am unconvinced. :-)
    >>
    >> Can you give an example of when the order in which objects are released

    is
    >> important?

    >
    >In cases where you have parent/child logical relationships you may want

    to
    >release child objects first. If you look at cases like the ADO model where
    >recordsets have references to the connection you need to clean up the
    >recordsets in order to be able to release the connection -- I've had similar
    >object interrelationships within my own objects where the order I released
    >things affected when system resources were gone. I like having that degree
    >of control, even if it is not a critical issue.


    Bob, what you are talking about here with ADO has nothing at all to do with
    setting object references to Nothing. Sure, there may be things you want
    to do with the recordset such as update and close before you are finished
    with the connection and recordset objects, but they are specific procedures
    you call explicitly. Don't confuse these issues. If you can't see the difference
    then you may end up in trouble sometime. If you don't update the recordset
    before setting the recordset object to nothing or it goes out of scope then
    that is an application bug, regardless of whether it happens because the
    reference has gone out of scope or you have set it to nothing. Remember
    that setting an object to Nothing does not in itself destroy the object,
    it just decrements its reference count.

    As an example, suppose yo have dimmed ADO Connection and Recordset objects.
    You set the Recordset object to the results of executing a SQL command with
    the Connection object. If you set the Connection object to Nothing at this
    point then you have not lost the connection to the database and the Connection
    object is not destroyed! There is still a reference to it in the ActiveConnection
    property of the Recordset object!

    Bob, by all means continue to code Set MyObject = Nothing if you like but
    don't get confused about object lifetime. As I said in a previous post,
    whe I see someone setting objects to nothing at the end of procedures and
    in terminate events I question them on object lifetime. The practice of blindly
    setting objects to nothing in these circumstances hides real problems.



  15. #30
    Andrew Jones Guest

    Re: Set MyObject=Nothing?

    I bet you're sorry you posted, Bob

    Why crucify the guy for disagreeing with you? He agrees that it's
    unnecessary. He's proven that he understands what's going on behind the
    scenes. But he still prefers to do it. Live and let live!

    Of course I'm saying this because I religiously set = nothing as well
    It's just a habit, and a reflection of the way I think about using objects.
    I want to create it (or obtain it from wherever), use it, and then ditch it
    as quickly as possible. So I tend to think I haven't "finished" using an
    object until I set = nothing so it can be freed if nothing else is hanging
    on to it. I KNOW that won't always free the memory straight away, but much
    of the time it does. I KNOW that if I'm doing it right before an End Sub it
    is completely and utterly pointless and useless, but I do it anyway. It's a
    habit and I think there are an AWFUL lot more serious bad habits out there
    that you could be criticising!

    Just my 2c!



    "Bob Butler" <butlerbob@earthlink.net> wrote in message
    news:39f2e07b@news.devx.com...
    > "Michael Culley" <m_culley@one.net.au> wrote in message
    > news:39f2d315$1@news.devx.com...
    > > A better example would be do you set variables to default values at the

    > start
    > > of functions?

    >
    > That's still not a good example but in most cases if I depend on a

    specific
    > value being there I do set it, even if it is the default. I've been

    burned
    > more than once in various languages when default behavior changed and I've
    > learned not to rely on it when I can easily avoid it.
    >
    > > I had a poke around to see what VB does and it seams that it still does

    > the
    > > Set Obj=Nothing itself even if you do it.

    >
    > Yes, it does. I do not argue that. What I do believe is that having the
    > code do it explicitly shows me exactly when and where in my code I no

    longer
    > need it. It also serves to remind me to call any .Close or other method
    > needed to shut down cleanly. I see a lot of code where people rely on the
    > variable going out of scope and then rely on the termination doing
    > cleanup... I've always held that better to take complete control over the
    > lifetime of any objects you use and the upcoming changes in VB.Net are

    going
    > to force people to do just that in a lot more cases.
    >
    > The current versions of VB handle it for you and do it properly (at least

    in
    > most cases - I do not know offhand of any objects that do not shut down
    > cleanly now although I have seen them in the past. One early DAO version,
    > for example, did not properly release resources if you did not explicitly
    > close recordsets and/or databases.) If you are comfortable in relying on
    > the VB cleanup now then by all means do so. I always try to code with an
    > eye towards moving to new versions and/or other languages down the line so

    I
    > prefer to be as explicit as possible. For me it has paid off in the past
    > and it looks like it's going to make VB.Net easier to adopt.
    >
    > > There is one case where I use it and that is in terminate events for

    > object
    > > dimmed at the module level.

    >
    > Why? When the module goes out of scope, or the app ends, the references
    > will be released. You don't trust VB to do that correctly somehow? As

    long
    > as you do not have circular references set up it will all be handled
    > automatically...
    >
    > As far as I'm concerned, always releasing references lets you control the
    > order and timing and makes the code more self-documenting.
    >
    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center