Even C++ had this much right... - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 7 FirstFirst 12345 ... LastLast
Results 31 to 45 of 95

Thread: Even C++ had this much right...

  1. #31
    Rob Teixeira Guest

    Re: Even C++ had this much right...



    Hmm, same here. I thought a lot about this, and it just keeps going in circles.
    There's no real plausable way to reasonably introduce DF. Personally, I have
    absolutely no problem calling Close or Dispose. But the cyclical problem
    goes as follows:
    a) Some people will forget or not be aware that they should call Close/Dispose.
    This is reminiscent of the circular-ref problem in VB6, which in a sense
    is ironically part of the reason for GC in the first place.
    b) On the other hand, I have yet to see someone who got bitten by circular-ref
    not learn their lesson - IOW, they didn't do it again once they understood
    what hit them. I think we can reasonably expect that people will learn to
    use Close/Dispose.
    c) That still doesn't really address a)

    At any rate, I'm not in favor of another value type for resources, especially
    with those types of restrictions. I'm currently working with an idea that
    revolves around a compiler switch that deals with classes marked with IDispose.
    The compiler switch is there because, while the feature grants you a safety
    net, it also implies a performance penalty. Therefore, if you don't want
    the safty net, you can turn it off. The idea I'm still milling around in
    my head would allow you to keep resources out of a special value type, and
    at the same time be able to depend on scope. It's still not perfect, and
    has a long way to go, so I'll post it as I get a clearer picture.

    -Rob

    zane@mabry.com (Zane Thomas) wrote:
    >On Sat, 18 Aug 2001 10:54:27 -0700, "Ronald Laeremans [MSFT]"
    ><ronlaere@microsoft.com> wrote:
    >
    >>How would you (and fellow VB developers) feel if resource objects were

    a
    >>special type that had some restrictions? I.e. they would be value types
    >>(stack or static allocated) and you could not put them into collections,

    or
    >>box them, or include them in other value types (but you would be able to
    >>include them in other resource type classes) and there would be perhaps

    1
    >>special case collection object you could store them in.

    >
    >Hmm, can't speak for the vb developers here, but as a c# developer I
    >really wouldn't like that. I don't have a problem remembering to invoke
    >Close or Whatever as required on certain types of objects.
    >
    >
    >--
    >The nice thing about standards is that
    >there are so many of them to choose from.



  2. #32
    Rob Teixeira Guest

    Re: Even C++ had this much right...


    Sounds like a great plan to me. After all, I'm tired of hearing one camp saying
    "give *OUR* language more power", and then hearing another camp (sometimes
    with the same people) saying "stop making *OUR* language more complex!".

    Not that it was really *THEIR* language in the first place, but finding a
    good way to deal with both sides would be most welcome.

    -Rob

    "Michael \(michka\) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote:
    >
    >Also fortunately, they are rethinking this whole "every language is equal"
    >thing and, as in Ronald's note earlier, they are going to allow some
    >features to be driven by the users of each language -- so that no one pays
    >the price of either too much complexity or too much simplicity, merely
    >because others seem to need it. :-)
    >
    >--
    >MichKa
    >
    >Michael Kaplan
    >Trigeminal Software, Inc.
    >http://www.trigeminal.com/
    >
    >
    >



  3. #33
    Kathleen Dollard Guest

    Re: Even C++ had this much right...

    Larry,

    > > A class that may connect to external data transparently to the

    programmer.
    > > Or one where the connection management may change over time, or based on
    > > scenario (for example, a class that can work over a LAN or a Internet
    > > connection depending on user location. Where the connection is dropped

    over
    > > the LAN, but a dial-up connection is maintained. The using programmer
    > > doesn't even need to know how it deprecates.

    >
    > I am under the impression, that should not be effected by GC or DF. In

    either
    > case you have determined the connection type, so when a class making the
    > the connection (using a connection class) is done with the connection,

    that
    > connection class is either released to the GC (LAN) , or held open

    (Dial-up)
    > until the class who is using the connection is no longer needed.


    I am confused by what you are suggesting here.

    > > Data retrieved from an Excel application. Where the spreadsheet, and

    Excel
    > > should be released when the object no longer exists, but where the

    object
    > > has no meaning except representing the underlying Excel data. And, oh,

    btw,
    > > if the spreadsheet is redesigned such that I want the data fed into

    memory
    > > then Excel released,
    > >
    > > Are those the kind of specifics you were looking for?

    >
    > Yes except that your second issue went over my head... <g>
    >
    > "has no meaning except representing the underlying Excel data"


    K, a class that is the CEO's personal and salary information. The UI has no
    reason to know _anything_ about where this comes from. Could come from an
    Excel spreadsheet that you would like to release when you are done with it.
    Could be stateless where you have no need to release. The UI should not know
    this detail.

    > > I don't want a legacy Dispose/Close method to confuse
    > > future programmers.

    >
    > Dispose is the future, that _will_ be expected in .Net, correct?


    Dispose is a huge step backward. It requires the using code/programmer to
    know more than they should about the class (in some cases they have to know
    this anyway). It is not robust in a changing environment. That said, we will
    probably have to live with it in many cases.

    > > My biggest concern about DF is the evolving
    > > class where external changes shift the decision about what to do with

    the
    > > resource. The lack of DF means that shifting this decision either force
    > > significant change in existing apps, or legacy crap (unneeded
    > > Dispose/Close).
    > >

    >
    > Thanks for responding, but perhaps I am to foggy minded (at this early

    hour)
    > to groc what you are refering to. I can understand how external

    conditions
    > might effect how you want to respond, but I fail to see how that relates

    to DF....

    You write a class that treats its resources in a stateless manner
    (disconnect/reconnect). No need for the clients to call dispose and they
    don't. Sometime later the scenario changes, and with no change to the
    external interface you want/need to handle the resource in a statful manner
    (retain connection). You are screwed.

    We are getting away from the technical aspects of this thread. We should
    move to dotnet.discussion to continue this subthread (I have set Follow-up
    to that).

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --



  4. #34
    Patrice Scribe Guest

    Re: Even C++ had this much right...

    a) If you have to call Dispose/Close at Finalization time you could just
    issue a warning (raise an exception ?) to allow the developer to be aware of
    this and fix the problem. A standard mechanism that allows to report this
    programming error could be perhaps enough rather than to take care directly
    of the (so-called ?) DF problem....

    After all even with DF there is nothing that prevents keeping an object
    around even when you have no more need for it. A standard performance
    counter could allow to know how much "sensible" resources are kept around
    currently....

    Just thinking loud....

    Patrice

    Rob Teixeira <RobTeixeira@@msn.com> a écrit dans le message :
    3b81170c$1@news.devx.com...
    >
    >
    > Hmm, same here. I thought a lot about this, and it just keeps going in

    circles.
    > There's no real plausable way to reasonably introduce DF. Personally, I

    have
    > absolutely no problem calling Close or Dispose. But the cyclical problem
    > goes as follows:
    > a) Some people will forget or not be aware that they should call

    Close/Dispose.
    > This is reminiscent of the circular-ref problem in VB6, which in a sense
    > is ironically part of the reason for GC in the first place.
    > b) On the other hand, I have yet to see someone who got bitten by

    circular-ref
    > not learn their lesson - IOW, they didn't do it again once they understood
    > what hit them. I think we can reasonably expect that people will learn to
    > use Close/Dispose.
    > c) That still doesn't really address a)
    >
    > At any rate, I'm not in favor of another value type for resources,

    especially
    > with those types of restrictions. I'm currently working with an idea that
    > revolves around a compiler switch that deals with classes marked with

    IDispose.
    > The compiler switch is there because, while the feature grants you a

    safety
    > net, it also implies a performance penalty. Therefore, if you don't want
    > the safty net, you can turn it off. The idea I'm still milling around in
    > my head would allow you to keep resources out of a special value type, and
    > at the same time be able to depend on scope. It's still not perfect, and
    > has a long way to go, so I'll post it as I get a clearer picture.
    >
    > -Rob
    >
    > zane@mabry.com (Zane Thomas) wrote:
    > >On Sat, 18 Aug 2001 10:54:27 -0700, "Ronald Laeremans [MSFT]"
    > ><ronlaere@microsoft.com> wrote:
    > >
    > >>How would you (and fellow VB developers) feel if resource objects were

    > a
    > >>special type that had some restrictions? I.e. they would be value types
    > >>(stack or static allocated) and you could not put them into collections,

    > or
    > >>box them, or include them in other value types (but you would be able to
    > >>include them in other resource type classes) and there would be perhaps

    > 1
    > >>special case collection object you could store them in.

    > >
    > >Hmm, can't speak for the vb developers here, but as a c# developer I
    > >really wouldn't like that. I don't have a problem remembering to invoke
    > >Close or Whatever as required on certain types of objects.
    > >
    > >
    > >--
    > >The nice thing about standards is that
    > >there are so many of them to choose from.

    >






  5. #35
    Ronald Laeremans [MSFT] Guest

    Re: Even C++ had this much right...

    inline. Parts snipped.

    > > Note that DF as exposed by VB 6 is used for several different scenarios,

    of
    > > which not all fit the same pattern and need to be solved by the same
    > > solution in the .NET world

    >
    > You might want to watch out for that. That is not necessarily the case.

    It
    > may happen that two (or more) different solutions are needed to address
    > and recover from all of the cases you have listed.

    That is what I meant, the not was supposed to apply to everything that
    followed.

    <...>

    > > 1) My type encapsulates a scarce resource of which there is only 1, and

    I
    > > need DF in my programming model. Example: A file object. I want it to be
    > > closed from the moment I am done with it, because otherwise it stays

    locked
    > > and I can't create a new instance that references to the same underlying
    > > file.

    >
    > I was thinking the older style Open and Close statements would not be a

    problem,
    > whereas using Sytem.IO (File) classes would exhibit the problem above. If

    that
    > is the case, then the solution for this would be to use the older format.

    Otherwise,
    > if they need that single resource repeatedly, and can't normally get at it

    (again) until
    > after a GC cycle, then (for the most part) they are not done with it until

    the app ends...
    What you are suggesting is a VB-specific, compiler based solution that would
    wrap the System.IO classes in a compiler provided DF wrapper. Unless
    omitting the close leaves the file in an open state until your app
    terminates, in which case it really solves nothing, and is only more
    palatable for existing VB 1-6 users because in those situations they had to
    get it right before. Do note that a lot of components expose similar types
    of resources in classes, and they could not use a solution like this.

    > > 2) My type encapsulates no resource, I am just using scope to trigger an
    > > action. Example: the famous Wait Cursor class.

    >
    > I was thinking this is a tough one to solve, without using a scope based

    solution.
    > And, as I said in another post, we may need to find some way to provide a

    means
    > to fall back to a default condition for an object's properties, once the

    object that set
    > them falls out of scope. As you said, this is a brainstorming session,

    so let me
    > suggest this:
    >
    > Consider an object as a tablet (table of properties) with a set of onion

    skins that
    > overlay the tablet. When a user creates an object, it fires up with a

    predetermined
    > set of property values. For each routine that sets properties on that

    object, a new
    > layer of onion skin is laid on top of the tablet. Meaning a duplicate

    object is
    > created except this object has it properties set to the new values. These

    skins
    > would be dependant on the class were the subroutine is. So that, when an
    > object/class gets placed in the GC que, any skins it created become

    unreachable.
    > The creation of these skins happen on a procedural level, so that the

    first property
    > set creates a new instance (onion skin) which is referenced for the

    remainder of
    > that procedure. This allows the user to set and use different properties

    in different
    > sections of the procedure, without them all creating a new 'skin'. When

    the
    > procedure ends, that skin is 'overlayed' on the tablet so that the runtime

    sees
    > all the changes made. Meaning the original object (reference) is held in

    reserve,
    > and the object (reference) with the changed properties is substituted for

    all future
    > calls. Under normal circumstances, when the user releases the object, it

    simply
    > waits in the GC que to be destroyed. The reserved object gets GC'ed and

    the skins
    > become invalid. If that object is non destructable, as is the case in the

    Wait Cursor
    > case where the App still has a reference to the Form so it cannot be

    destroyed, then
    > only the onion skins become invalid (their 'creator' is in the GC que) and

    its most
    > recent (still valid) skins are the ones used by the runtime.
    >
    > As I see it, the tricky part is how to maintain an onion skin so that

    everyone knows
    > which one to use. To work as planned, any class that changes properties

    on an
    > (global) object has to inform the runtime engine that it now holds the

    current reference
    > to that object. Also, the runtime engine has to keep a list of who owned

    the 'current
    > reference' so that if the object it thought had the current reference is

    no longer
    > available, it can 'unwind' the list until it finds a valid object, so that

    a reference to
    > its onion skin can be used. In this way, its the objects who hold

    references to
    > the skins, so that when such an object gets placed in the GC que, any and

    all
    > of the skins it holds become unreachable. The bad news is that these

    skins would
    > multiply like rabbits, but as their name suggests they should be extremely

    light,
    > even if the object they represent is complex.
    >
    > This is not scope based, in that references are not destroyed (placed in

    the que)
    > because some object went out of scope, but it acts like it is because the

    skins
    > that were created become unreachable when the object that created them

    gets
    > placed in the que. To clarify, a skin should be less than a shallow copy

    of an object
    > with a few properties set to different values.
    >
    > Again, this is just a suggestion, and it is apparent that such a solution,

    if found
    > workable, would (almost) need to be implemented in (or near) the base

    Object
    > class so that (nearly) all objects exhibit the onion skin idea.

    I'll analyse this a bit further, but it looks like a very heavy
    weight-mechanism to me and you would need to provide more detail about how
    it would work. E.g. what does your solution do for:

    In routine 1:
    Create such an object
    start up a thread that executes routine 2 passing it a reference/copy/skin
    of the object
    loop
    lock object
    update some property

    In routine 2:
    Create such an object
    start up a thread that executes routine 2 passing it a reference/copy/skin
    of the object
    loop
    lock object
    update some property

    > > 3) My type encapsulates a resource of which there are just a very few.
    > > Example: a handle to a DC in Win9x (there are only 5, but not other GDI
    > > objects you can allocate several hundreds or thousands). DB connection
    > > handles for a DB licensed through a connection count and not a connected
    > > user or other mechanism could fall into the same category.

    >
    > We have to work inside the boundries of the language, so it seems to me,

    this
    > is similar to #1, in that the object referenced should not be released

    until the
    > app is done with it. The fact that there are only a few available is a

    result of
    > the object provider's decision, is it not? It will be up to them to

    decide what a
    > more appropreate value would be, running on the .Net platform. For

    example,
    > why are there only 5 hDC handles in Win9x, as you state? I know that is

    now
    > a limitation, due to Win9x already being released, but in the future, such
    > limitations might be given more consideration. That could then be solved

    by
    > attrition (older versions falling out of use) rather than changes to the

    platform.
    So you are saying this problem isn't worth fixing. If you could convince
    e.g. Oracle about making the underlying issue go away, I am sure many folks
    would be happy.<g>

    <...>



  6. #36
    Jonathan Wood Guest

    Re: Even C++ had this much right...

    Ronald,

    > You should include the install for the .NET runtime with your program


    Well, that's what I was saying: that I need to make sure the users obtains
    the 10s of MBs of runtime that work with my program. Before you seemed to
    disagree but here you seem to be agreeing.

    > or
    > have the install point to the Microsoft site where it can be downloaded.


    In addition to confusing some of my customers (trust me on that one), that
    Microsoft site will probably have the latest version of the runtime and not
    the one that is compatible with my program.

    > I might be missing the magic bullet you are thinking of that would get an
    > application vendor out of supporting any of these options and still having
    > their application work with future side-by-side versions of the CLR (or of
    > any runtime for that matter).


    My point is simply that, with C++, I can write a (more or less) stand-alone
    EXE file that will continue to work for my customers unless MS releases an
    incompatible version of Windows down the road. But with .NET, I better make
    sure the customer has those 10s of MBs of runtime or my program will fail if
    any portion of the .NET runtime that it uses becomes incompatible.

    I'm not looking for a magic bullet. I just see this as something that
    impacts the value of software I sell if I develop it using .NET.

    > BTW, I don't see how you will be able to assume the current version of the
    > runtime will be on all machines in any near future. E.g. Windows 98, NT 4
    > client, Windows 2000 will not be going away anywhere soon. While the CLR
    > install will be available in many forms, I think you will be guaranteed

    that
    > quite a few users will not have it on their machines in the next few

    years.

    Right. So, again, you seem to be agreeing that I need to distribute my .NET
    applications with 10s of MBs of runtime. I'm not making a judgement about
    how good or bad that is, I'm just looking for it to be recognized that this
    is the case.

    --
    Jonathan Wood
    SoftCircuits Programming
    http://www.softcircuits.com



  7. #37
    Jonathan Wood Guest

    Re: Even C++ had this much right...

    Larry,

    > Dispose is the future, that _will_ be expected in .Net, correct?


    Dang! I was hoping OOP was the future.

    Will you just call Dispose on every object you use? Don't forget any. Or
    maybe you'll just call it on those that needs it. Will you always know which
    ones those are? And what if they change? And what about when unexpected
    errors happen in your program?

    --
    Jonathan Wood
    SoftCircuits Programming
    http://www.softcircuits.com



  8. #38
    Jonathan Allen Guest

    Re: Even C++ had this much right...

    > I think we can reasonably expect that people will learn to
    > use Close/Dispose.


    And if they don't, is it really a big deal? The GC will eventually get
    around to doing it, unlike circular references which never get cleaned up.

    --
    Jonathan Allen


    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3b81170c$1@news.devx.com...
    >
    >
    > Hmm, same here. I thought a lot about this, and it just keeps going in

    circles.
    > There's no real plausable way to reasonably introduce DF. Personally, I

    have
    > absolutely no problem calling Close or Dispose. But the cyclical problem
    > goes as follows:
    > a) Some people will forget or not be aware that they should call

    Close/Dispose.
    > This is reminiscent of the circular-ref problem in VB6, which in a sense
    > is ironically part of the reason for GC in the first place.
    > b) On the other hand, I have yet to see someone who got bitten by

    circular-ref
    > not learn their lesson - IOW, they didn't do it again once they understood
    > what hit them. I think we can reasonably expect that people will learn to
    > use Close/Dispose.
    > c) That still doesn't really address a)
    >
    > At any rate, I'm not in favor of another value type for resources,

    especially
    > with those types of restrictions. I'm currently working with an idea that
    > revolves around a compiler switch that deals with classes marked with

    IDispose.
    > The compiler switch is there because, while the feature grants you a

    safety
    > net, it also implies a performance penalty. Therefore, if you don't want
    > the safty net, you can turn it off. The idea I'm still milling around in
    > my head would allow you to keep resources out of a special value type, and
    > at the same time be able to depend on scope. It's still not perfect, and
    > has a long way to go, so I'll post it as I get a clearer picture.
    >
    > -Rob
    >




  9. #39
    Larry Serflaten Guest

    Re: Even C++ had this much right...


    "Ronald Laeremans [MSFT]" <ronlaere@microsoft.com>

    > What you are suggesting is a VB-specific, compiler based solution that would
    > wrap the System.IO classes in a compiler provided DF wrapper.


    Really, I was suggesting that the 'best practises' approach would simply state
    that if rapid opening and closing is needed, then use the older style statements.
    Yes, this was a VB specific suggestion, thats the language I 'think' in, (and it the
    language this group is geared toward). I was under the impression that using
    Open and Close commands was not a significant performance hit, and that
    the normal practise for handling files is to get in, and get out, the quicker the better.
    I was thinking that Open/Close would still be using the OS API, but I see now that,
    under the covers, they could be running against managed objects and/or the CLR.

    > Unless
    > omitting the close leaves the file in an open state until your app
    > terminates,


    It _almost_ sounds like you thought I meant that the Close statement would be
    sitting in a Finalize routine. What I meant was, supposing I want to expose a
    Random Access (flat) DB as a collection of records, then for a GetRecord method
    that class should open the file, get the record, and close the file before returning.
    Again, I thought that would be the end of it, but it seems you indicated that no, there
    is some managed object that used to provide the older syntax. This is where I should
    really be looking at the MSIL to see what is going on, before opening my mouth only
    to insert my foot!

    > in which case it really solves nothing, and is only more
    > palatable for existing VB 1-6 users because in those situations they had to
    > get it right before. Do note that a lot of components expose similar types
    > of resources in classes, and they could not use a solution like this.


    That's partly my problem, I am not well versed in all the different resources
    developers need to expose, nor the problems they have in moving to .Net.
    Yet another reason to watch, listen, and learn... <g>

    >
    > > > 2) My type encapsulates no resource, I am just using scope to trigger an
    > > > action. Example: the famous Wait Cursor class.

    > >
    > > I was thinking this is a tough one to solve, without using a scope based solution.
    > > And, as I said in another post, we may need to find some way to provide a means
    > > to fall back to a default condition for an object's properties, once the
    > > object that set them falls out of scope. (IE. Lands in the GC queue)


    > I'll analyse this a bit further, but it looks like a very heavy
    > weight-mechanism to me and you would need to provide more detail about how
    > it would work. E.g. what does your solution do for:
    >
    > In routine 1:
    > Create such an object
    > start up a thread that executes routine 2 passing it a reference/copy/skin
    > of the object
    > loop
    > lock object
    > update some property
    >
    > In routine 2:
    > Create such an object
    > start up a thread that executes routine 2 passing it a reference/copy/skin
    > of the object
    > loop
    > lock object
    > update some property
    >


    Whoosh! I am not up to par on how threads are syncronized in VB6, so until
    then, I could not make any sort of informed comment, sorry. My first guess
    would be along these lines. ResourceA is created, and passed to ObjectB.
    ObjectB sets a few properties which causes the creation of Skin1. A new
    thread is created for ObjectC and is given Skin1 to operate on. Any more
    changes in ObjectB are reflected in Skin1. Up to now Skin1 is used by the
    runtime as the active reference to ResourceA. Now ObjectC sets a few
    properties which forces Skin2 to be created. We now have a syncronization
    problem that needs resolving. If I knew how syncronization was handled
    currently I might be better equiped to continue! But, as there is only one
    actual ResourceA, I would have to guess that unless told to create a new
    resource for the new thread, all the changes needed to be reflected on
    the object, so in essence, because there is only one resource (for those
    cases were there is only one, say, Screen object) ObjectC in the new thread
    should not be allowed to create a new skin, it should be told (via thread
    attributes?) that all changes need to effect the Skin1 which it was passed.

    Then you want to lock updates, and in my book, that should effect the
    active reference so that if anyone locks the updates, no one can make
    changes.

    Again, I spoke up simply to provide an idea, you could have very possibly
    heard something similar before. But on the outside chance that it may
    inspire someone more knowlegable than I.... (There is also the chance that
    I have thought of something not very workable, from a 'return on investment'
    perspective. If/when that becomes obvious, all I can offer is a '...nevermind'
    in a friendly sort of way!)

    > > > 3) My type encapsulates a resource of which there are just a very few.


    > > We have to work inside the boundries of the language, so it seems to me,
    > > this is similar to #1


    > So you are saying this problem isn't worth fixing. If you could convince
    > e.g. Oracle about making the underlying issue go away, I am sure many folks
    > would be happy.<g>
    >


    Well, when the analysts realize they can only offer what the providers supply,
    then they are going to start looking for more friendly providers, are they not?
    Attrition, and market forces, take time.... <g>

    LFS




  10. #40
    Larry Serflaten Guest

    Re: Even C++ had this much right...


    "Jonathan Wood" <jwood@softcircuits.com> wrote

    > Right. So, again, you seem to be agreeing that I need to distribute my .NET
    > applications with 10s of MBs of runtime. I'm not making a judgement about
    > how good or bad that is, I'm just looking for it to be recognized that this
    > is the case.


    Then again, did you think you were going to distribute your applications on
    floppies? You test your app against the runtime you have, and include that
    on the CD. The installation program determines if they need it or not....

    What I see as the problem is when Version 1 uses 60Mb, then V2 uses 80
    and V3 uses 98, etc... Along about V5, the user has 3 programs from V1,
    6 from V2, 12 from V3 and so on. Now to simutaniously run 3 differnt apps,
    from 3 different versions (or more) requires that the system support hundreds
    of megabytes of runtime code.

    That may be a problem...

    LFS




  11. #41
    Larry Serflaten Guest

    Re: Even C++ had this much right...


    "Jonathan Wood" <jwood@softcircuits.com> wrote
    > Larry,
    >
    > > Dispose is the future, that _will_ be expected in .Net, correct?

    >
    > Dang! I was hoping OOP was the future.
    >
    > Will you just call Dispose on every object you use? Don't forget any. Or
    > maybe you'll just call it on those that needs it. Will you always know which
    > ones those are? And what if they change? And what about when unexpected
    > errors happen in your program?


    As it stands, I expect to use Dispose about as often as I currently use

    Set oThis = Nothing

    Basically, If I don't use New, I don't expect to use Dispose. I also expect
    that I will let things slide that don't exhibit problems. For instance a class I might
    build and create to organize/manipulate some data. If I provide a dispose, that
    basically does nothing, then why bother calling it? OTOH, if Dispose is actually
    'supposed' to supress the GC's finalize call, then I had better do that, and would
    gain performance benefits, if I use it.

    LFS





  12. #42
    Willy Van den Driessche Guest

    Re: Even C++ had this much right...

    "Larry Serflaten" <serflaten@usinternet.com> wrote in message
    news:3b8186c7$1@news.devx.com...
    >
    > "Jonathan Wood" <jwood@softcircuits.com> wrote
    >
    > > Right. So, again, you seem to be agreeing that I need to distribute my

    ..NET
    > > applications with 10s of MBs of runtime. I'm not making a judgement

    about
    > > how good or bad that is, I'm just looking for it to be recognized that

    this
    > > is the case.

    >
    > Then again, did you think you were going to distribute your applications

    on
    > floppies? You test your app against the runtime you have, and include

    that
    > on the CD. The installation program determines if they need it or not....


    You may make fun of it but it really IS a serious issue. For me, program
    footprint is less of an issue, since I have 80Gb to spend. But my customers
    don't. All they will see is they have an application that is twice as big
    in installation and does exactly the same as the old program. How do we
    explain them ?
    Also, installations overthe internet will be very prohibitive. 10Mb over a
    56K modem takes a lot of time.
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



  13. #43
    Bob Butler Guest

    Re: Even C++ had this much right...


    "Larry Serflaten" <serflaten@usinternet.com> wrote in message
    news:3b81894b@news.devx.com...
    <cut>
    > If I provide a dispose, that
    > basically does nothing, then why bother calling it?


    What happens when your object doesn't need Dispose now but you add something
    in V2 that does need it? If your client code isn't calling Dispose then you
    have to search out and update all references or leave existing clients
    calling an old version of the object. Neither is a good solution IMO.




  14. #44
    Bob Butler Guest

    Re: Even C++ had this much right...

    "Larry Serflaten" <serflaten@usinternet.com> wrote in message
    news:3b8186c7$1@news.devx.com...
    <cut>
    > What I see as the problem is when Version 1 uses 60Mb, then V2 uses 80
    > and V3 uses 98, etc... Along about V5, the user has 3 programs from V1,
    > 6 from V2, 12 from V3 and so on.


    Is it possible to install the runtimes in the application directory? If so,
    there's a potential for a lot of bloat very quickly. If not then it's an
    issue of having several versions of the runtimes (probably more like 20-25MB
    each) and that's not great, but nowhere near as bad.




  15. #45
    Larry Serflaten Guest

    Re: Even C++ had this much right...


    "Bob Butler" <butlerbob@earthlink.net> wrote

    > > What I see as the problem is when Version 1 uses 60Mb, then V2 uses 80
    > > and V3 uses 98, etc... Along about V5, the user has 3 programs from V1,
    > > 6 from V2, 12 from V3 and so on.

    >
    > Is it possible to install the runtimes in the application directory? If so,
    > there's a potential for a lot of bloat very quickly. If not then it's an
    > issue of having several versions of the runtimes (probably more like 20-25MB
    > each) and that's not great, but nowhere near as bad.


    I guess I did not make myself clear, or maybe the problem I was mentioning
    wasn't going to be a problem....

    With side-by-side versioning, all of these apps will require that their runtime
    be installed, and running. While 100+ megabytes on the HD might also be a
    problem, the amount actually loaded should be as small as possible, to avoid
    the problem I suggested, as the years go by....

    It also may be that by the time we think the problem might develop, the industry
    standard PC might be significantly more capable.... No doubt, time will tell....

    LFS






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