DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 4 123 ... LastLast
Results 1 to 15 of 47

Thread: Ok, who loves GC now?

  1. #1
    Zane Thomas Guest

    Ok, who loves GC now?


    Having now written some serious code with .net I gotta tell you that I
    really like the garbage collector. It makes many things so much less
    complicated. That translates to more functionality with less bugs in
    finished code.

    Anyone change their minds about GC yet?


    ---
    Ice Z - Straight Outta Redmond

  2. #2
    Michael \(michka\) Kaplan Guest

    Re: Ok, who loves GC now?

    I haven't, but none of the projects that keep me from being excited about it
    are typical, so I recognize that the things keep me fro excitement are not
    necessarily typical.

    --
    MichKa

    a new book on internationalization in VB at
    http://www.i18nWithVB.com/

    "Zane Thomas" <zane@mabry.com> wrote in message
    news:3a42a845.26022640@news.devx.com...
    >
    > Having now written some serious code with .net I gotta tell you that I
    > really like the garbage collector. It makes many things so much less
    > complicated. That translates to more functionality with less bugs in
    > finished code.
    >
    > Anyone change their minds about GC yet?
    >
    >
    > ---
    > Ice Z - Straight Outta Redmond




  3. #3
    Bill McCarthy Guest

    Re: Ok, who loves GC now?

    Hi Zane,

    "Zane Thomas" <zane@mabry.com> wrote in message
    news:3a42a845.26022640@news.devx.com...
    >
    > Having now written some serious code with .net I gotta tell you that I
    > really like the garbage collector. It makes many things so much less
    > complicated. That translates to more functionality with less bugs in
    > finished code.


    How so (on both counts) ??.

    From a VB perspective I have not seen any advantage at all, actually the
    opposite. For resource expensive objects you have to remember to call
    dispose. And when the object is declared at anything other than procedure
    level, then it means you have to make sure that everything else is finished
    with it, or another thread isn't accessing it etc.





  4. #4
    Zane Thomas Guest

    Re: Ok, who loves GC now?

    Bill,

    >> It makes many things so much less
    >> complicated. That translates to more functionality with less bugs in
    >> finished code.

    >
    >How so (on both counts) ??.


    Glad you asked. :-)

    But before answering that:

    >From a VB perspective I have not seen any advantage ...


    That's because you don't yet have components written in c# or mc++ you can
    use. I've been writing some stuff with both of those languages and so...

    Count 1: Not having to deal with maintaining correct reference counts and
    freeing memory when done with it is very nice.

    Count 2: That gives me more time to implement features and makes for code
    which is less prone to errors and bugs.

    Sorry y'all vb programmers had to take on the teensy problem of making
    sure that some things are disposed of properly, but you're paying a small
    price for what the rest of us got. :-)

    Currently I'm working on a Socket class which has some significant
    advantages over System.Net.Sockets.Socket, not the least of which is
    timeouts everywhere you could want them. I'll let you know when it's
    ready for beta - which should be soon given the ease with which I can now
    write components. Thanks again, your suffering shall be repaid. :-)






    ---
    Ice Z - Straight Outta Redmond

  5. #5
    Gray Guest

    Re: Ok, who loves GC now?

    Comments inline.

    Zane Thomas <zane@mabry.com> wrote in message
    news:3a45c663.33732609@news.devx.com...

    > That's because you don't yet have components written in c# or mc++ you can
    > use. I've been writing some stuff with both of those languages and so...


    But we aren't (or were not prior to .net ... grin...) writing in C++. We
    were writing in VB.

    >
    > Count 1: Not having to deal with maintaining correct reference counts and
    > freeing memory when done with it is very nice.


    But we didn't in VB ...

    >
    > Count 2: That gives me more time to implement features and makes for code
    > which is less prone to errors and bugs.


    Solved by previous comment.

    >
    > Sorry y'all vb programmers had to take on the teensy problem of making
    > sure that some things are disposed of properly, but you're paying a small
    > price for what the rest of us got. :-)
    >


    You sure you're not working for MS ? grin...

    > ---
    > Ice Z - Straight Outta Redmond




  6. #6
    Zane Thomas Guest

    Re: Ok, who loves GC now?

    Gray,

    >But we aren't (or were not prior to .net ... grin...) writing in C++. We
    >were writing in VB.


    Geesh, you VBers sure show a stunning lack of compassion for your fellow
    programmers. Not to mention the fact that all the new stuff you got, like
    inheritance and threading, more than makes up for the very minor annoyance
    of having to know about the GC.

    I'll bet that most vb.net programmers won't really care what language the
    components they use are written in - as long as they're small, fast, and
    good. Dotnet sure makes me a lot more productive than I was using ATL, the
    result will be more for less.

    >You sure you're not working for MS ? grin...


    Nah, I'm working for myself. :-)


    ---
    Ice Z - Straight Outta Redmond

  7. #7
    Gray Guest

    Re: Ok, who loves GC now?

    Probally 'cause we're spoiled... grin...
    Actually from what I've seen, I like .NET so far.
    As far as my apps go, as long as at some point in time everything gets
    de-allocated automagically then I'm happy.
    I'm more irritated by the syntax changes than anything else. ie the property
    sets and gets etc...
    It doesn't affect my use of the language but c'mon when I want to use C++ I
    use C++ ... grin...
    If this keeps up then there won't be any difference between C# and .NET.
    (Except for curly braces maybe ..)

    Zane Thomas <zane@mabry.com> wrote in message
    news:3a47d301.36962437@news.devx.com...
    > Gray,
    >
    > >But we aren't (or were not prior to .net ... grin...) writing in C++. We
    > >were writing in VB.

    >
    > Geesh, you VBers sure show a stunning lack of compassion for your fellow
    > programmers. Not to mention the fact that all the new stuff you got, like
    > inheritance and threading, more than makes up for the very minor annoyance
    > of having to know about the GC.
    >
    > I'll bet that most vb.net programmers won't really care what language the
    > components they use are written in - as long as they're small, fast, and
    > good. Dotnet sure makes me a lot more productive than I was using ATL, the
    > result will be more for less.
    >
    > >You sure you're not working for MS ? grin...

    >
    > Nah, I'm working for myself. :-)
    >
    >
    > ---
    > Ice Z - Straight Outta Redmond




  8. #8
    Bill McCarthy Guest

    Re: Ok, who loves GC now?

    Hi Zane,

    "Zane Thomas" <zane@mabry.com> wrote in message
    news:3a45c663.33732609@news.devx.com...
    > Bill,
    >
    > >> It makes many things so much less
    > >> complicated. That translates to more functionality with less bugs in
    > >> finished code.

    > >
    > >How so (on both counts) ??.

    >
    > Glad you asked. :-)
    >
    > But before answering that:
    >
    > >From a VB perspective I have not seen any advantage ...

    >
    > That's because you don't yet have components written in c# or mc++ you can
    > use. I've been writing some stuff with both of those languages and so...
    >


    LOL!! I should have known it was a cross language troll <bg>












  9. #9
    Jonathan Allen Guest

    Re: Ok, who loves GC now?

    > From a VB perspective I have not seen any advantage at all, actually the
    > opposite. For resource expensive objects you have to remember to call
    > dispose.


    That's a lot easier to catch and correct than a circular reference. Also,
    it's not automatically fatal. If you don't dispose it, it will almost
    certainly be finalized eventually.

    > And when the object is declared at anything other than procedure
    > level, then it means you have to make sure that everything else is

    finished
    > with it, or another thread isn't accessing it etc.


    I doubt threads will be common problem. Resource dependant classes are
    generally single use anyways. For instance, you'll never have two threads
    writing to the same file stream.

    As for global resource classes, this is generally a bad idea. If it's a
    resource, then chances are you will want to close it ASAP. I see global
    classes that open and return resource classes as being more common.

    Also, I believe there is a GC command to trigger pending finalizers
    immediately. You could release your copy of the global resource, then call
    it. If it is truly released, then finalize will be called.

    --
    Jonathan Allen


    "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
    news:3a41bb6b@news.devx.com...
    > Hi Zane,
    >
    > "Zane Thomas" <zane@mabry.com> wrote in message
    > news:3a42a845.26022640@news.devx.com...
    > >
    > > Having now written some serious code with .net I gotta tell you that I
    > > really like the garbage collector. It makes many things so much less
    > > complicated. That translates to more functionality with less bugs in
    > > finished code.

    >
    > How so (on both counts) ??.
    >
    > From a VB perspective I have not seen any advantage at all, actually the
    > opposite. For resource expensive objects you have to remember to call
    > dispose. And when the object is declared at anything other than procedure
    > level, then it means you have to make sure that everything else is

    finished
    > with it, or another thread isn't accessing it etc.
    >
    >
    >
    >




  10. #10
    Bill McCarthy Guest

    Re: Ok, who loves GC now?


    "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    news:3a421a21@news.devx.com...
    >
    > That's a lot easier to catch and correct than a circular reference. Also,
    > it's not automatically fatal. If you don't dispose it, it will almost
    > certainly be finalized eventually.
    >


    Hey, circular references aren't necessarily fatal either. More on this
    below...

    >
    > I doubt threads will be common problem. Resource dependant classes are
    > generally single use anyways. For instance, you'll never have two threads
    > writing to the same file stream.
    >


    I think you missed the point. If, as I said, the object is declared at
    anything *other* than procedure level, you have potential problems in
    deciding when to call dispose on it. If a thread returns before or after
    another or proc returns then you don't know in which one the object should
    be disposed of in.

    > As for global resource classes, this is generally a bad idea. If it's a
    > resource, then chances are you will want to close it ASAP. I see global
    > classes that open and return resource classes as being more common.
    >


    Oh really ??? Wouldn't that design be reliant on finalisers instead of
    dispose ?

    > Also, I believe there is a GC command to trigger pending finalizers
    > immediately. You could release your copy of the global resource, then call
    > it. If it is truly released, then finalize will be called.
    >


    With only one *major* drawback. You have to call a complete GC.







  11. #11
    Jonathan Allen Guest

    Re: Ok, who loves GC now?

    > I think you missed the point. If, as I said, the object is declared at
    > anything *other* than procedure level, you have potential problems in
    > deciding when to call dispose on it.


    My point was that resource using classes should be used only be used in
    procedures, regardless if you are writing a VB, VB.Net, or even C++ program.
    The problems with not having DF is just one of the many reasons for this.

    --
    Jonathan Allen


    "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
    news:3a421eab@news.devx.com...
    >
    > "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    > news:3a421a21@news.devx.com...
    > >
    > > That's a lot easier to catch and correct than a circular reference.

    Also,
    > > it's not automatically fatal. If you don't dispose it, it will almost
    > > certainly be finalized eventually.
    > >

    >
    > Hey, circular references aren't necessarily fatal either. More on this
    > below...
    >
    > >
    > > I doubt threads will be common problem. Resource dependant classes are
    > > generally single use anyways. For instance, you'll never have two

    threads
    > > writing to the same file stream.
    > >

    >
    > I think you missed the point. If, as I said, the object is declared at
    > anything *other* than procedure level, you have potential problems in
    > deciding when to call dispose on it. If a thread returns before or after
    > another or proc returns then you don't know in which one the object should
    > be disposed of in.
    >
    > > As for global resource classes, this is generally a bad idea. If it's a
    > > resource, then chances are you will want to close it ASAP. I see global
    > > classes that open and return resource classes as being more common.
    > >

    >
    > Oh really ??? Wouldn't that design be reliant on finalisers instead of
    > dispose ?
    >
    > > Also, I believe there is a GC command to trigger pending finalizers
    > > immediately. You could release your copy of the global resource, then

    call
    > > it. If it is truly released, then finalize will be called.
    > >

    >
    > With only one *major* drawback. You have to call a complete GC.
    >
    >
    >
    >
    >
    >




  12. #12
    Bill McCarthy Guest

    Re: Ok, who loves GC now?


    "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    news:3a42258a@news.devx.com...
    >
    > My point was that resource using classes should be used only be used in
    > procedures, regardless if you are writing a VB, VB.Net, or even C++

    program.
    > The problems with not having DF is just one of the many reasons for this.
    >


    "one of the many reasons" ?? care to ellaborate on that ??

    The lack of DF has made timely disposal of shared resources extremely
    difficult. The only way to do it is to add reference counting back in on
    top of the GC. So far, the things you have said actually highlight what I
    originally said. The lack of DF in VB.NET makes things more problematic.

    BTW: I really don't want to rehash this again. I think Zane was just having
    a bit of fun, and it should be left at that. I can't believe that you could
    seriously argue that on one hand you should only have procedure level
    classes that are using resources and on the other hand you should haplessly
    write circular references everywhere and not bother about timely cleaning up
    of them. You can imagine what happens when they reference the "global
    classes that open and return resource classes" about which you seem to be
    advocating as some form of design utopia.











  13. #13
    Jonathan Allen Guest

    Re: Ok, who loves GC now?

    > "one of the many reasons" ?? care to ellaborate on that ??

    I would be glad too. Much of the following was explained to me when I said
    "but can't I just wait for it to go out of scope" in reference to VB6 and
    ASP.

    1. Safety.
    Generally, you don't want two procedures messing around with the same
    resource object.

    I remember way back when I had global recordsets for static data. Two
    procedures were stomping on each other because both changed the current
    record. It has hard to detect because each procedure was valid on it's own
    merits. Now imagine if that had been a live resource like a file stream. The
    entire file could have been fraged.

    This is compounded by threads that can be simultaneously messing with it.

    2. Performance
    On multi-user systems, you want to release the object the moment it is
    no longer needed, not just wait for it to go out of scope. Even in some
    functions that can be a long time.

    2b. DB Connections
    According to someone at MS ( I talked to him in the ADO.Net newsgroup),
    DB connections shouldn't be persisted in an application wide variable.
    Connection pooling is more effective when they are requested and released
    only when needed.

    Also, there are (for lack of a better term) threading issues with ADO.Net.
    If you have a forward-only cursor, then you cannot open a second recordset
    until the first is done.

    3. Fault-Tolerance
    Another reason not to leave resources open is in case of a system crash.
    It's a simple case of creating a smaller target. The less time a resource is
    open, the less chance that a system crash will occur while it's open and
    frag it.

    --
    Jonathan Allen


    "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
    news:3a4227dc@news.devx.com...
    >
    > "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    > news:3a42258a@news.devx.com...
    > >
    > > My point was that resource using classes should be used only be used in
    > > procedures, regardless if you are writing a VB, VB.Net, or even C++

    > program.
    > > The problems with not having DF is just one of the many reasons for

    this.
    > >

    >
    > "one of the many reasons" ?? care to ellaborate on that ??
    >
    > The lack of DF has made timely disposal of shared resources extremely
    > difficult. The only way to do it is to add reference counting back in on
    > top of the GC. So far, the things you have said actually highlight what I
    > originally said. The lack of DF in VB.NET makes things more problematic.
    >
    > BTW: I really don't want to rehash this again. I think Zane was just

    having
    > a bit of fun, and it should be left at that. I can't believe that you

    could
    > seriously argue that on one hand you should only have procedure level
    > classes that are using resources and on the other hand you should

    haplessly
    > write circular references everywhere and not bother about timely cleaning

    up
    > of them. You can imagine what happens when they reference the "global
    > classes that open and return resource classes" about which you seem to be
    > advocating as some form of design utopia.
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >




  14. #14
    Zane Thomas Guest

    Re: Ok, who loves GC now?

    On Fri, 22 Dec 2000 02:55:35 +1100, "Bill McCarthy"
    <Bill_McC@iprimus.com.au> wrote:

    >The lack of DF has made timely disposal of shared resources extremely
    >difficult.


    I think Jonathan's point was that you should design to avoid those sorts
    of problems wherever possible.

    My point, yes it was a bit of a troll for fun too, was that vb.net is sooo
    much cooler than VB6. Given all the new functionality I find it downright
    silly for people to have focused so much attention on GC and DF. Have you
    played with threading in vb.net? And what about the new IDE? Yeah, I
    blow it up every hour or so. But even now it's a great enhancement to
    productivity, imo.

    I could go on, but I'm sure you get my point, there are good points and
    bad points (yeah, compatability, I didn't forget). I think the good far
    outweighs the bad.


    ---
    Ice Z - Straight Outta Redmond

  15. #15
    Bill McCarthy Guest

    Re: Ok, who loves GC now?


    "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    news:3a42773e@news.devx.com...
    > > "one of the many reasons" ?? care to ellaborate on that ??

    >
    > I would be glad too. Much of the following was explained to me when I said
    > "but can't I just wait for it to go out of scope" in reference to VB6 and
    > ASP.
    >
    > 1. Safety.
    > Generally, you don't want two procedures messing around with the same
    > resource object.
    >


    So are you saying you never have module level variables ?? Doesn't that
    hamper your class design somewhat ?

    > I remember way back when I had global recordsets for static data. Two
    > procedures were stomping on each other because both changed the current
    > record. It has hard to detect because each procedure was valid on it's own
    > merits. Now imagine if that had been a live resource like a file stream.

    The
    > entire file could have been fraged.
    >


    Have a look at the IEnumerator in the CLR. I think you'll see that the issue
    you raise here is more to do with how you access the shared resource, not
    the useage of shared resources.

    > This is compounded by threads that can be simultaneously messing with it.
    >
    > 2. Performance
    > On multi-user systems, you want to release the object the moment it is
    > no longer needed, not just wait for it to go out of scope. Even in some
    > functions that can be a long time.
    >


    Exactly. This is something that has been lost in the GC world compared to
    VB6.


    > 2b. DB Connections
    > According to someone at MS ( I talked to him in the ADO.Net

    newsgroup),
    > DB connections shouldn't be persisted in an application wide variable.
    > Connection pooling is more effective when they are requested and released
    > only when needed.
    >
    > Also, there are (for lack of a better term) threading issues with ADO.Net.
    > If you have a forward-only cursor, then you cannot open a second recordset
    > until the first is done.
    >


    Huh ?? I must be missing somethign there ? If you aren't sharing the
    resource, doesn't that mean all other threads will have to be halted. Sounds
    like a reason to use a shared resource.


    > 3. Fault-Tolerance
    > Another reason not to leave resources open is in case of a system

    crash.
    > It's a simple case of creating a smaller target. The less time a resource

    is
    > open, the less chance that a system crash will occur while it's open and
    > frag it.
    >


    That's dependant on whether or not the resource is one that requires the
    information to be stored.







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