A (not so) basic question.

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Cor Ligthert [MVP]

    #16
    Re: A (not so) basic question.

    Goran,

    There are no more arguments to give in this thread, Jay has given them all
    as an analyse what is often discussed in this newsgroup, so maybe can you
    read those before you write messages and answer than that thread as you need
    to do that.

    Cor

    "Göran Andersson" <guffa@guffa.co m> schreef in bericht
    news:%23$HphLLh GHA.1208@TK2MSF TNGP02.phx.gbl. ..[color=blue]
    > When someone run out of arguments, they tend to attack the person instead.
    > I must say that it was a pretty lame attack, though...
    >
    > Cor Ligthert [MVP] wrote:[color=green]
    >> Goran,
    >>
    >> Feel free to do it that way.
    >>
    >> You probably set as well all used values at null at the end of a method?
    >>
    >> Cor[/color][/color]


    Comment

    • Cor Ligthert [MVP]

      #17
      Re: A (not so) basic question.

      One other thing,

      Breaking the code by changing existing members as dispose another meaning or
      something extra, is one of the last things that ever will be done. Despite
      what somebody active in another newsgroup forever writes.

      Cor

      "Göran Andersson" <guffa@guffa.co m> schreef in bericht
      news:%23$HphLLh GHA.1208@TK2MSF TNGP02.phx.gbl. ..[color=blue]
      > When someone run out of arguments, they tend to attack the person instead.
      > I must say that it was a pretty lame attack, though...
      >
      > Cor Ligthert [MVP] wrote:[color=green]
      >> Goran,
      >>
      >> Feel free to do it that way.
      >>
      >> You probably set as well all used values at null at the end of a method?
      >>
      >> Cor[/color][/color]


      Comment

      • Göran Andersson

        #18
        Re: A (not so) basic question.

        Cor Ligthert [MVP] wrote:[color=blue]
        > Goran,
        >
        > There are no more arguments to give in this thread, Jay has given them all
        > as an analyse what is often discussed in this newsgroup,[/color]

        So the Mighty Jay has spoken, and there is no room for argument?

        If you want to refer to something that someone else wrote, why didn't
        you do that instead of trying to patronise me?
        [color=blue]
        > so maybe can you
        > read those before you write messages and answer than that thread as you need
        > to do that.[/color]

        Need to do what? I am unable to distinguish if you are referring to
        reading the "analyse", write messages or answer that thread.
        [color=blue]
        >
        > Cor
        >
        > "Göran Andersson" <guffa@guffa.co m> schreef in bericht
        > news:%23$HphLLh GHA.1208@TK2MSF TNGP02.phx.gbl. ..[color=green]
        >> When someone run out of arguments, they tend to attack the person instead.
        >> I must say that it was a pretty lame attack, though...
        >>
        >> Cor Ligthert [MVP] wrote:[color=darkred]
        >>> Goran,
        >>>
        >>> Feel free to do it that way.
        >>>
        >>> You probably set as well all used values at null at the end of a method?
        >>>
        >>> Cor[/color][/color]
        >
        >[/color]

        Comment

        • Jay B. Harlow [MVP - Outlook]

          #19
          Re: A (not so) basic question.

          Cor,
          | 20% of all classes (and in that the most used) just implement disposable
          | because they inherit from Component.model . Examples of that. All classes
          in
          | control, all classes in system.data.
          I suspect higher then 20%...

          I would still call Dispose on them, as you need to use a tool such as ILDASM
          or Reflector to accurately determine if the dispose does anything
          interesting or not... Rather then rely on implementation details that are
          subject to change, I recommend simply always calling Dispose as my list
          suggests.

          | The connection by instance removes the reference to the
          | ConnectionStrin g to the object (and not anything more).
          Which connection? SqlConnection? SqlConnection does a lot more in its
          Dispose then simply removing the reference to the ConnectionStrin g!
          SqlConnection also calls its Close method & other stuff! This is easily
          verified with ILDASM or Reflector...



          --
          Hope this helps
          Jay B. Harlow [MVP - Outlook]
          ..NET Application Architect, Enthusiast, & Evangelist
          T.S. Bradley - http://www.tsbradley.net


          "Cor Ligthert [MVP]" <notmyfirstname @planet.nl> wrote in message
          news:%23Kr26yJh GHA.4656@TK2MSF TNGP04.phx.gbl. ..
          |
          | > After reading the comments of Jay B. Harlow, my conclusion is: when you
          | > create an object that is disposable, do it in such a way that you can
          | > dispose of it.
          |
          | But that has Jay no where written. You have read it without the word
          | *itself* implement Idisposable.
          |
          | 20% of all classes (and in that the most used) just implement disposable
          | because they inherit from Component.model . Examples of that. All classes
          in
          | control, all classes in system.data.
          |
          | Be aware about what Jay than wrote as well as soon as they are overridden
          in
          | fact than they implement Idispsable itself. You can than still decide if
          you
          | want to use it. The connection by instance removes the reference to the
          | ConnectionStrin g to the object (and not anything more).
          |
          | Cor
          |
          |


          Comment

          • Jay B. Harlow [MVP - Outlook]

            #20
            Re: A (not so) basic question.

            | When to call Dispose?

            One "exception" I forgot to list:

            * Do not explicitly call Dispose on classes deriving from
            System.Componen tModel.Componen t for instances placed on a
            System.Windows. Forms.Form as Form will implicitly dispose of them when the
            form is Disposed.

            --
            Hope this helps
            Jay B. Harlow [MVP - Outlook]
            ..NET Application Architect, Enthusiast, & Evangelist
            T.S. Bradley - http://www.tsbradley.net


            "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @tsbradley.net> wrote in
            message news:en$6PPzgGH A.4776@TK2MSFTN GP05.phx.gbl...
            | Roland,
            | In addition to the other comments: I would use a variation of your first
            | method:
            |
            | .NET 1.x
            | Dim fnt as Font = New Font(...)
            | Try
            | DrawString(myTe xt, fnt,...)
            | Finally
            | ' assuming fnt is not nothing
            | fnt.dispose().
            | End Try
            |
            |
            | .NET 2.0
            | Using fnt as Font = New Font(...)
            | DrawString(myTe xt, fnt,...)
            | End Using
            |
            | As this ensure that any unmanaged resources that Font may be exposing (as
            | evidenced by the fact that Font implements IDisposable) are released in a
            | timely manner. As you have pointed out. The GC may take minutes or longer
            to
            | release the resource, this may cause undue pressure on both the GC &
            Win32.
            | The GC as it is tracking a number of Finalizable objects, Win32 as you are
            | using Handles longer then necessary.
            |
            |
            | When to call Dispose?
            |
            | * Call Dispose when the type itself implements IDisposable
            |
            | * Call Dispose when the type or one of its base classes *overrides*
            | Dispose(Boolean ) if the class inherits from
            System.Componen tModel.Componen t
            | or System.Componen tModel.MarshalB yValueComponent
            |
            | * Do not explicitly call Dispose on classes deriving from
            | System.Windows. Forms.Control for instances placed on a
            | System.Windows. Forms.Form as Form will implicitly dispose of them when the
            | form is Disposed
            |
            | * Call Dispose on System.Windows. Forms.Form objects when Form.ShowDialog
            is
            | used.
            |
            | * Do not explicitly call Dispose on System.Windows. Forms.Form objects if
            | Form.Show is used as Dispose will be implicitly called when the form is
            | closed
            |
            | * Do not explicitly call Dispose on classes deriving from
            | System.Web.UI.C ontrol as it will be implicitly called as part of the
            normal
            | ASP.NET page processing
            |
            | I consider the second rule controversial as it relies on using ILDASM or
            | Reflector to find out implementation details of a class. Its meant for
            | classes such as DataSet, that have an inherited Dispose, but Dispose
            doesn't
            | really do anything.
            |
            | These rules are based on private discussions with other MVPs & discussions
            | held in the newsgroups earlier in 2005.
            |
            | These rules apply to objects that you create, explicitly or implicitly.
            | Objects that you "own".
            |
            | Disposable Objects that are passed to you as a parameter of a method (such
            | as the Graphics object on the Paint event) should not have their disposed
            | method call, as the system calls it as part of the method that raises the
            | event.
            |
            | Objects that something else "owns" should normally be disposed of by the
            | "owning" object.
            |
            |
            |
            | --
            | Hope this helps
            | Jay B. Harlow [MVP - Outlook]
            | .NET Application Architect, Enthusiast, & Evangelist
            | T.S. Bradley - http://www.tsbradley.net
            |
            |
            | "Roland" <roland.demeest er@skynet.be> wrote in message
            | news:e2Xu3gkgGH A.1612@TK2MSFTN GP04.phx.gbl...
            || The following issue is puzzling me:
            ||
            || There are 2 ways of writing the code below:
            || ...
            || Dim fnt as Font = New Font(...)
            || DrawString(myTe xt, fnt,...)
            || fnt.dispose().
            ||
            || or
            || DrawString(myTe xt, New Font(...),...)
            ||
            || The difference between both is that in the second case, there is no way
            to
            || explicitely dispose of the object (in the example, a Font object, but
            that
            || is purely circumstantial) . The basic issue is:
            ||
            || If an object is substantiated while passed a a parameter (as above), is
            it
            || inherently disposed by the called procedure (here: drawstring) or isn't
            it
            || at all?
            ||
            || The reason for this question is that I favor using the second way of
            | coding,
            || because it much less verbose, but I am not sure about the consequences.
            ||
            || Can anybody shed some light on that? Thanks in advance.
            ||
            ||
            |
            |


            Comment

            • Jay B. Harlow [MVP - Outlook]

              #21
              Re: A (not so) basic question.

              Cor,
              No that guy is "correct", note that he states "The only difference is that
              Dispose *also* clears the connection
              string."

              Notice the word "also" in there; using Reflector (or ILDASM) one can see
              that SqlConnection.D ispose(Boolean) clears the connection string, then calls
              Close. Dispose also does some pool cleanup work...

              --
              Hope this helps
              Jay B. Harlow [MVP - Outlook]
              ..NET Application Architect, Enthusiast, & Evangelist
              T.S. Bradley - http://www.tsbradley.net


              "Cor Ligthert [MVP]" <notmyfirstname @planet.nl> wrote in message
              news:esaocKNhGH A.4864@TK2MSFTN GP03.phx.gbl...
              | Herfried,
              |
              | You mean that this guy is wrong, I think that somebody has to inform him
              | before things go really wrong.
              | Because that you have seen this, than maybe can you send him a message.
              |
              |

              |
              | The only thing you can say is that the dispose is generic used in the
              using
              | statement.
              | But in that is as well not generic a catch, something I am not so happy
              | with,
              |
              | Cor
              |
              | "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> schreef in bericht
              | news:%23rJz7PMh GHA.1204@TK2MSF TNGP02.phx.gbl. ..
              | > "Cor Ligthert [MVP]" <notmyfirstname @planet.nl> schrieb:
              | >> Feel free to do it that way.
              | >>
              | >> You probably set as well all used values at null at the end of a
              method?
              | >
              | > Sorry Cor, but Göran is right. It definitely makes sense to call the
              | > 'Dispose' method whenever its available because implementing the
              | > 'IDisposable' interface simply says "call the 'Dispose' method after
              using
              | > the object to free unmanaged resources occupied by the object". Even if
              | > currently no unmanaged resources are released at all inside the method's
              | > implementation, this might be the case in a future version. There are
              | > some rare cases where I'd not call the 'Dispose' method, but the reason
              | > for this is mainly that I do not care about the time when the resources
              | > are released.
              | >
              | > --
              | > M S Herfried K. Wagner
              | > M V P <URL:http://dotnet.mvps.org/>
              | > V B <URL:http://classicvb.org/petition/>
              |
              |


              Comment

              • Cor Ligthert [MVP]

                #22
                Re: A (not so) basic question.

                Jay,

                The guy is writing "one of them is enough", not explitly telling which and
                as I remember some more messages from him in the AdoNet newsgroup he points
                more on the close than the dispose. I know that dispose does something more,
                the question is if it is adding functionality and should be therefore in the
                code.

                I can make a piece of program like this.
                \\\
                For i As Integer = 0 To 1000000
                dt1.Rows(i)("co unter") = 1
                ds.Dispose()
                Next
                ///
                It does nothing (not even spent much time). However in my opinion does it
                suggest something that not is done and should therefore not be in a program.

                That every dispose acts as well as a close where that should be done is
                obvious. The using is (as you know) from the first day in C# and therefore
                that is needed.

                Just my opinion.

                Cor

                "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @tsbradley.net> schreef in
                bericht news:eVNHhaQhGH A.4252@TK2MSFTN GP04.phx.gbl...[color=blue]
                > Cor,
                > No that guy is "correct", note that he states "The only difference is that
                > Dispose *also* clears the connection
                > string."
                >
                > Notice the word "also" in there; using Reflector (or ILDASM) one can see
                > that SqlConnection.D ispose(Boolean) clears the connection string, then
                > calls
                > Close. Dispose also does some pool cleanup work...
                >
                > --
                > Hope this helps
                > Jay B. Harlow [MVP - Outlook]
                > .NET Application Architect, Enthusiast, & Evangelist
                > T.S. Bradley - http://www.tsbradley.net
                >
                >
                > "Cor Ligthert [MVP]" <notmyfirstname @planet.nl> wrote in message
                > news:esaocKNhGH A.4864@TK2MSFTN GP03.phx.gbl...
                > | Herfried,
                > |
                > | You mean that this guy is wrong, I think that somebody has to inform him
                > | before things go really wrong.
                > | Because that you have seen this, than maybe can you send him a message.
                > |
                > |
                > http://groups.google.com/group/micro...5919344c3c556a
                > |
                > | The only thing you can say is that the dispose is generic used in the
                > using
                > | statement.
                > | But in that is as well not generic a catch, something I am not so happy
                > | with,
                > |
                > | Cor
                > |
                > | "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> schreef in bericht
                > | news:%23rJz7PMh GHA.1204@TK2MSF TNGP02.phx.gbl. ..
                > | > "Cor Ligthert [MVP]" <notmyfirstname @planet.nl> schrieb:
                > | >> Feel free to do it that way.
                > | >>
                > | >> You probably set as well all used values at null at the end of a
                > method?
                > | >
                > | > Sorry Cor, but Göran is right. It definitely makes sense to call the
                > | > 'Dispose' method whenever its available because implementing the
                > | > 'IDisposable' interface simply says "call the 'Dispose' method after
                > using
                > | > the object to free unmanaged resources occupied by the object". Even
                > if
                > | > currently no unmanaged resources are released at all inside the
                > method's
                > | > implementation, this might be the case in a future version. There are
                > | > some rare cases where I'd not call the 'Dispose' method, but the
                > reason
                > | > for this is mainly that I do not care about the time when the
                > resources
                > | > are released.
                > | >
                > | > --
                > | > M S Herfried K. Wagner
                > | > M V P <URL:http://dotnet.mvps.org/>
                > | > V B <URL:http://classicvb.org/petition/>
                > |
                > |
                >
                >[/color]


                Comment

                Working...