Even C++ had this much right...


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 7 123 ... LastLast
Results 1 to 15 of 95

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

  1. #1
    Derek Mooney Guest

    Even C++ had this much right...


    After reading the article about safe typecasting, I followed the link to Stroustrup's
    FAQ. I found this one really interesting:

    -------------------------

    Why doesn't C++ provide a "finally" construct?

    Because C++ supports an alternative that is almost always better: The "resource
    acquisition is initialization" technique (TC++PL3 section 14.4). The basic
    idea is to represent a resource by a local object, so that the local object's
    destructor will release the resource. That way, the programmer cannot forget
    to release the resource. For example:
    class File_handle {
    FILE* p;
    public:
    File_handle(const char* n, const char* a)
    { p = fopen(n,a); if (p==0) throw Open_error(errno); }
    File_handle(FILE* pp)
    { p = pp; if (p==0) throw Open_error(errno); }

    ~File_handle() { fclose(p); }

    operator FILE*() { return p; }

    // ...
    };

    void f(const char* fn)
    {
    File_handle f(fn,"rw"); // open fn for reading and writing
    // use file through f
    }

    In a system, we need a "resource handle" class for each resource. However,
    we don't have to have an "finally" clause for each acquisition of a resource.
    In realistic systems, there are far more resource acquisitions than kinds
    of resources, so the "resource acquisition is initialization" technique leads
    to less code than use of a "finally" construct.
    Also, have a look at the examples of resource management in Appendix E of
    The C++ Programming Language.

    -------------------------

    In a language such as C++, the idea was that it was best to enclose resources
    inside classes so that "the programmer cannot forget to release the resource"!
    Yet in .NET we MUST use a finally clause in EVERYTHING that uses a resource
    class, and call Close() and/or Dispose() in that finally clause, if we want
    to ensure that resources are cleaned up correctly.

    This is (and has been) my one and only complaint about .NET -- I certainly
    understand the benefit of garbage collection when dealing with systems of
    many small objects whose resource usage is only memory. But for applications
    that work with other types of resources frequently, .NET becomes cumbersome
    and as error-prone to code in as straight C.

    How hard would it be to add a facility for reference counting to ensure cleanup
    of resources as soon as they go out of scope!

    Derek

  2. #2
    Ronald Laeremans [MSFT] Guest

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

    Hi Derek,

    Very hard, but that does not mean we are not investigating possible
    solutions.

    If you want to see a quite detailed analysis of what the difficulties are
    see the following post on the Developmentor .NET mailing list:

    http://discuss.develop.com/archives/...OTNET&P=R28572

    If you have comments after reading that, please post them here and I can try
    to address them. Don't take that mail above as meaning that we stopped our
    investigation, the comments to that effect in there pertain to what we could
    do fort this version.

    -Ronald-

    "Derek Mooney" <derek@brownstone.net> wrote in message
    news:3b7d2a0b$1@news.devx.com...
    >
    > After reading the article about safe typecasting, I followed the link to

    Stroustrup's
    > FAQ. I found this one really interesting:
    >
    > -------------------------
    >
    > Why doesn't C++ provide a "finally" construct?
    >
    > Because C++ supports an alternative that is almost always better: The

    "resource
    > acquisition is initialization" technique (TC++PL3 section 14.4). The basic
    > idea is to represent a resource by a local object, so that the local

    object's
    > destructor will release the resource. That way, the programmer cannot

    forget
    > to release the resource. For example:
    > class File_handle {
    > FILE* p;
    > public:
    > File_handle(const char* n, const char* a)
    > { p = fopen(n,a); if (p==0) throw Open_error(errno); }
    > File_handle(FILE* pp)
    > { p = pp; if (p==0) throw Open_error(errno); }
    >
    > ~File_handle() { fclose(p); }
    >
    > operator FILE*() { return p; }
    >
    > // ...
    > };
    >
    > void f(const char* fn)
    > {
    > File_handle f(fn,"rw"); // open fn for reading and writing
    > // use file through f
    > }
    >
    > In a system, we need a "resource handle" class for each resource. However,
    > we don't have to have an "finally" clause for each acquisition of a

    resource.
    > In realistic systems, there are far more resource acquisitions than kinds
    > of resources, so the "resource acquisition is initialization" technique

    leads
    > to less code than use of a "finally" construct.
    > Also, have a look at the examples of resource management in Appendix E of
    > The C++ Programming Language.
    >
    > -------------------------
    >
    > In a language such as C++, the idea was that it was best to enclose

    resources
    > inside classes so that "the programmer cannot forget to release the

    resource"!
    > Yet in .NET we MUST use a finally clause in EVERYTHING that uses a

    resource
    > class, and call Close() and/or Dispose() in that finally clause, if we

    want
    > to ensure that resources are cleaned up correctly.
    >
    > This is (and has been) my one and only complaint about .NET -- I certainly
    > understand the benefit of garbage collection when dealing with systems of
    > many small objects whose resource usage is only memory. But for

    applications
    > that work with other types of resources frequently, .NET becomes

    cumbersome
    > and as error-prone to code in as straight C.
    >
    > How hard would it be to add a facility for reference counting to ensure

    cleanup
    > of resources as soon as they go out of scope!
    >
    > Derek




  3. #3
    Derek Mooney Guest

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


    Very informative. I'm glad to know how seriously the problems were considered.

    I find it interesting that performance is such an issue in what is being
    pushed as a general purpose programming framework. In the past few years,
    performance has taken a back seat to developer productivity -- if I want
    performance, I take C++. If I want productivity, I take VB or ASP.

    While .NET claims to provide a "choice" of languages, you really only get
    the choice of the CLR. No tradeoffs between performance and productivity.
    Of course, a C++ compiler is thrown in there too, but it's not really there
    to help me solve any of the real shortcomings of the CLR.

    In an age where every program we get is upgraded every other year, and requires
    a new generation of processors to support it -- of which Microsoft is more
    guilty of than anybody -- MS's language design seems to have taken a step
    in the opposite direction. Rather than concentrating on making programmers
    more productive, the concentration is on performance.

    At some point in the future, the tradeoff will again balance from an emphasis
    on performance to an emphasis on productivity. In the meantime, I'll get
    really tired of writing try-finally blocks.

    At the bare minimum, something like the using() block would reduce the amount
    of code that developers would have to create to support the Dispose method.
    It might also pacify those complaining while a more permanent solution is
    sought.

    Derek



    "Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote:
    >Hi Derek,
    >
    >Very hard, but that does not mean we are not investigating possible
    >solutions.
    >
    >If you want to see a quite detailed analysis of what the difficulties are
    >see the following post on the Developmentor .NET mailing list:
    >
    >http://discuss.develop.com/archives/...OTNET&P=R28572
    >
    >If you have comments after reading that, please post them here and I can

    try
    >to address them. Don't take that mail above as meaning that we stopped our
    >investigation, the comments to that effect in there pertain to what we could
    >do fort this version.
    >
    >-Ronald-



  4. #4
    Craig Clearman Guest

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

    Derek,

    >At the bare minimum, something like the using() block would reduce the amount
    >of code that developers would have to create to support the Dispose method.


    C# has the using() block today, and you are right -- it does make
    resource management easier and more robust. You can put in a request
    to have the Visual Basic team do the same, but I personally wouldn't
    expect it in Version 1.0.

    Ciao, Craig


  5. #5
    Kathleen Dollard Guest

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

    Ronald,

    I think I have said this before, but since you said "_we_ are investigating"
    I will say this again.

    The vast majority of objects do not need DF. The few that do, really, really
    do. It can not be put off onto the domain programmer who should be unaware
    of the details of scarce resources. For this reason, it is OK for DF to be
    expensive. Not outrageously expensive, and we'd like it to be as efficient
    as possible, but we can intelligently make a decision as to whether to mark
    a specific class for DF. I realize that it is likely to not only be
    expensive during cleanup, but also during object creation.

    I am actually very glad we have GC. It allows a freedom in programming for
    object creation to be very, very cheap. However, the need for DF for a small
    number of objects is real and this is an important issue (not as important
    as code security or load times, but important).

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



  6. #6
    Ronald Laeremans [MSFT] Guest

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

    We are extremely serious about the ability of the .NET programming model to
    be high performance enough to write many applications that people have
    traditionally never even considered using anything but C/C++ (or maybe
    Delphi for a very few) for. You will definitely see many applications coming
    out of Microsoft over the next few years that are written in .NET languages
    and using the .NET framework. This would not be possible if the CLR itself
    did not concern itself with base line performance. And the 100% transparent
    fix for the DF issue, would have required either a ref-counted or a combined
    tracing/ref-counted gc system for all objects. Which would have lead to
    unacceptable performance penalties.

    What you are seeing now that I think prompts your "no tradeoffs" comments is
    a reflection on that fact that this is a brand-new platform. Going forward,
    you will see the different languages diverge again in how much they focus on
    ease of use and rapid development versus absolute control and performance.
    But I think if you looked a bit closer at the managed part of C++, even in
    this version, you will see that we offer quite a few ways already to "fix"
    some of the issues with the CLR (at the cost of loosing safety and
    verifiability of course). These are things like unsafe casts, explicit
    boxing, direct read-only access to the System.String buffer, the ability to
    directly use unmanaged data structures and the system heap and the ability
    to combine templates on unmanaged types with the gchandle class to build
    things (for MC++ consumption only) like a kind of auto_ptr equivalent of the
    C# using block for DF.

    The combination of a true-multi language system based upon a unified
    execution engine, AND (and this is a very important factor) having
    multi-language mean seamless interop between the languages combined with a
    desire to make this execution system be useful for 99% or so of all
    development tasks does present a lot of very challenging problems. Of which
    we solved quite a few in this release, and frankly of which we solved quite
    a few not so well, or not all in this release. The latter type we are
    working very hard on right now (yes, on this specific Saturday in my
    case<g>) for future releases.

    Ronald Laeremans
    Visual C++ compiler team, and general nuisance to many other teams

    "Derek Mooney" <derek@brownstone.net> wrote in message
    news:3b7d69a6@news.devx.com...
    >
    > Very informative. I'm glad to know how seriously the problems were

    considered.
    >
    > I find it interesting that performance is such an issue in what is being
    > pushed as a general purpose programming framework. In the past few years,
    > performance has taken a back seat to developer productivity -- if I want
    > performance, I take C++. If I want productivity, I take VB or ASP.
    >
    > While .NET claims to provide a "choice" of languages, you really only get
    > the choice of the CLR. No tradeoffs between performance and productivity.
    > Of course, a C++ compiler is thrown in there too, but it's not really

    there
    > to help me solve any of the real shortcomings of the CLR.
    >
    > In an age where every program we get is upgraded every other year, and

    requires
    > a new generation of processors to support it -- of which Microsoft is more
    > guilty of than anybody -- MS's language design seems to have taken a step
    > in the opposite direction. Rather than concentrating on making

    programmers
    > more productive, the concentration is on performance.
    >
    > At some point in the future, the tradeoff will again balance from an

    emphasis
    > on performance to an emphasis on productivity. In the meantime, I'll get
    > really tired of writing try-finally blocks.
    >
    > At the bare minimum, something like the using() block would reduce the

    amount
    > of code that developers would have to create to support the Dispose

    method.
    > It might also pacify those complaining while a more permanent solution is
    > sought.
    >
    > Derek





  7. #7
    Ronald Laeremans [MSFT] Guest

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

    I know.

    I'll ask you a question back.

    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.

    If you are OK with a _very_ expensive way, that would be almost trivial to
    implement. We could mark resource types in some way, and each time one went
    out of scope, we could trigger a full gc. A bit more efficient version is
    actually what we use in the Handle Collector idiom that the frameworks use
    for things like GDI handles: every time you have allocated n more (n depends
    on the type) a full gc is triggered.

    BTW, I am so glad this thread is in the technical newsgroup.<vbg>

    -Ronald-

    "Kathleen Dollard" <kathleen@nomailplease.org> wrote in message
    news:3b7e6a79@news.devx.com...
    > Ronald,
    >
    > I think I have said this before, but since you said "_we_ are

    investigating"
    > I will say this again.
    >
    > The vast majority of objects do not need DF. The few that do, really,

    really
    > do. It can not be put off onto the domain programmer who should be unaware
    > of the details of scarce resources. For this reason, it is OK for DF to be
    > expensive. Not outrageously expensive, and we'd like it to be as efficient
    > as possible, but we can intelligently make a decision as to whether to

    mark
    > a specific class for DF. I realize that it is likely to not only be
    > expensive during cleanup, but also during object creation.
    >
    > I am actually very glad we have GC. It allows a freedom in programming for
    > object creation to be very, very cheap. However, the need for DF for a

    small
    > number of objects is real and this is an important issue (not as important
    > as code security or load times, but important).
    >
    > --
    > Kathleen
    > (MS-MVP)
    > Reply in the newsgroup so everyone can benefit
    > --
    >
    >




  8. #8
    Zane Thomas Guest

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

    On Sat, 18 Aug 2001 10:48:35 -0700, "Ronald Laeremans [MSFT]"
    <ronlaere@microsoft.com> wrote:

    >[interesting problems] Of which
    >we solved quite a few in this release ...


    And y'all did a really great job with the .net platform, the more I learn
    about it the more impressed I am. An interesting exercise, I think, when
    examining the base classes is to ask "Why? Why was it done that way?" -
    the answer is often enlightening. Of course every once in a while the
    answer is: "Ooops, that's not quite right." :-) Try subclassing Socket
    and handling the EndAccept in a subclass for an example.




    --
    The nice thing about standards is that
    there are so many of them to choose from.

  9. #9
    Zane Thomas Guest

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

    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.

  10. #10
    Willy Van den Driessche Guest

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

    Very interesting stuff. I would be very pleased to find all these thoughts
    in something like an annotated .NET manual or book.

    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html
    "Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote in message
    news:3b7d3d63$1@news.devx.com...
    > Hi Derek,
    >
    > Very hard, but that does not mean we are not investigating possible
    > solutions.
    >
    > If you want to see a quite detailed analysis of what the difficulties are
    > see the following post on the Developmentor .NET mailing list:
    >
    > http://discuss.develop.com/archives/...OTNET&P=R28572
    >
    > If you have comments after reading that, please post them here and I can

    try
    > to address them. Don't take that mail above as meaning that we stopped our
    > investigation, the comments to that effect in there pertain to what we

    could
    > do fort this version.
    >
    > -Ronald-
    >
    > "Derek Mooney" <derek@brownstone.net> wrote in message
    > news:3b7d2a0b$1@news.devx.com...
    > >
    > > After reading the article about safe typecasting, I followed the link to

    > Stroustrup's
    > > FAQ. I found this one really interesting:
    > >
    > > -------------------------
    > >
    > > Why doesn't C++ provide a "finally" construct?
    > >
    > > Because C++ supports an alternative that is almost always better: The

    > "resource
    > > acquisition is initialization" technique (TC++PL3 section 14.4). The

    basic
    > > idea is to represent a resource by a local object, so that the local

    > object's
    > > destructor will release the resource. That way, the programmer cannot

    > forget
    > > to release the resource. For example:
    > > class File_handle {
    > > FILE* p;
    > > public:
    > > File_handle(const char* n, const char* a)
    > > { p = fopen(n,a); if (p==0) throw Open_error(errno); }
    > > File_handle(FILE* pp)
    > > { p = pp; if (p==0) throw Open_error(errno); }
    > >
    > > ~File_handle() { fclose(p); }
    > >
    > > operator FILE*() { return p; }
    > >
    > > // ...
    > > };
    > >
    > > void f(const char* fn)
    > > {
    > > File_handle f(fn,"rw"); // open fn for reading and writing
    > > // use file through f
    > > }
    > >
    > > In a system, we need a "resource handle" class for each resource.

    However,
    > > we don't have to have an "finally" clause for each acquisition of a

    > resource.
    > > In realistic systems, there are far more resource acquisitions than

    kinds
    > > of resources, so the "resource acquisition is initialization" technique

    > leads
    > > to less code than use of a "finally" construct.
    > > Also, have a look at the examples of resource management in Appendix E

    of
    > > The C++ Programming Language.
    > >
    > > -------------------------
    > >
    > > In a language such as C++, the idea was that it was best to enclose

    > resources
    > > inside classes so that "the programmer cannot forget to release the

    > resource"!
    > > Yet in .NET we MUST use a finally clause in EVERYTHING that uses a

    > resource
    > > class, and call Close() and/or Dispose() in that finally clause, if we

    > want
    > > to ensure that resources are cleaned up correctly.
    > >
    > > This is (and has been) my one and only complaint about .NET -- I

    certainly
    > > understand the benefit of garbage collection when dealing with systems

    of
    > > many small objects whose resource usage is only memory. But for

    > applications
    > > that work with other types of resources frequently, .NET becomes

    > cumbersome
    > > and as error-prone to code in as straight C.
    > >
    > > How hard would it be to add a facility for reference counting to ensure

    > cleanup
    > > of resources as soon as they go out of scope!
    > >
    > > Derek

    >
    >




  11. #11
    Larry Serflaten Guest

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


    "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?


    It gets harder to make the correct choice, when the number of possible
    choices increases. On a side note, this is part of the reasoning behind my
    suggesting that the New keyword be depreciated. It would be a big help
    (to novice, or domain expert programmers) if we could treat all the 'objects'
    in the same manner.

    Having said that, I would, however, have to weigh in on the side of providing the
    functionality, for those cases that actually need it. Kathy, or someone else will
    have to provide an example as I can't recall ever having to 'require' a dependancy
    on DF in any of my code.

    > If you are OK with a _very_ expensive way, that would be almost trivial to
    > implement. We could mark resource types in some way, and each time one went
    > out of scope, we could trigger a full gc.


    Thats your solution today. Maybe after a few years of actual use, another less
    expensive way might be 'discovered'. So again, I would be agreeable to seeing
    that functionality provided for, however you have to do it. Your suggestion of
    providing a special reference type (in _addition_ to the current reference types
    already avaliable) seems like a workable solution, for the time being.

    The question I have, is after they are released out to the masses, what if a
    better method is found (Supposing, for example, that you later use a second
    GC streamlined for just this purpose, or add to the current one, whatever) How
    is versioning going to be handled to avoid CLR bloat, as you move to a new
    and improved version 2, 3, and 4? Not only for this case, but for the CLR in
    general, what are MS's plans for backward compatability, or does MS think the
    CLR is pretty much written in stone, once it is realeased? (Not likely)

    (I am just paying Dan's advocate, wondering what MS's position is on code base
    stability for the long range future of VB.Net code) Are the quick fixes made now,
    going to bite us in the future? I half expect to hear mention of an upgrade wizard,
    but, to be honest, I don't put a lot of faith in mythical code!

    <g>
    LFS





  12. #12
    Larry Serflaten Guest

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


    "Larry Serflaten" <serflaten@usinternet.com> wrote
    > Kathy, or someone else will ...


    I am sorry, I meant to indicate Kathleen.

    LFS




  13. #13
    Ronald Laeremans [MSFT] Guest

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

    Long term evolution of APIs in the framework will probably involve
    deprecation of some individual APIs or API sets. As you might know there are
    facilities in the CLR (the deprecated attribute) with all compilers MS ships
    supporting that facility. I think we will actually ship version 1 with a few
    APIs already marked as deprecated.<g>

    Note that existing programs (with the default policy) will just execute with
    the version (plus patches) of the runtime they were developed against; so
    that is definitely a big part of the side by side story. As far as source
    code compatibility is concerned, I don't even think we ever broke
    compatibility going forward _on the same API platform_ to any significant
    degree. So I don't think it is likely we are going to in the future.

    -Ronald-

    "Larry Serflaten" <serflaten@usinternet.com> wrote in message
    news:3b7ed0be$1@news.devx.com...
    >
    > "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?

    >
    > It gets harder to make the correct choice, when the number of possible
    > choices increases. On a side note, this is part of the reasoning behind

    my
    > suggesting that the New keyword be depreciated. It would be a big help
    > (to novice, or domain expert programmers) if we could treat all the

    'objects'
    > in the same manner.
    >
    > Having said that, I would, however, have to weigh in on the side of

    providing the
    > functionality, for those cases that actually need it. Kathy, or someone

    else will
    > have to provide an example as I can't recall ever having to 'require' a

    dependancy
    > on DF in any of my code.
    >
    > > If you are OK with a _very_ expensive way, that would be almost trivial

    to
    > > implement. We could mark resource types in some way, and each time one

    went
    > > out of scope, we could trigger a full gc.

    >
    > Thats your solution today. Maybe after a few years of actual use, another

    less
    > expensive way might be 'discovered'. So again, I would be agreeable to

    seeing
    > that functionality provided for, however you have to do it. Your

    suggestion of
    > providing a special reference type (in _addition_ to the current reference

    types
    > already avaliable) seems like a workable solution, for the time being.
    >
    > The question I have, is after they are released out to the masses, what if

    a
    > better method is found (Supposing, for example, that you later use a

    second
    > GC streamlined for just this purpose, or add to the current one, whatever)

    How
    > is versioning going to be handled to avoid CLR bloat, as you move to a new
    > and improved version 2, 3, and 4? Not only for this case, but for the CLR

    in
    > general, what are MS's plans for backward compatability, or does MS think

    the
    > CLR is pretty much written in stone, once it is realeased? (Not likely)
    >
    > (I am just paying Dan's advocate, wondering what MS's position is on code

    base
    > stability for the long range future of VB.Net code) Are the quick fixes

    made now,
    > going to bite us in the future? I half expect to hear mention of an

    upgrade wizard,
    > but, to be honest, I don't put a lot of faith in mythical code!
    >
    > <g>
    > LFS





  14. #14
    Larry Serflaten Guest

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


    "Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote
    > As far as source
    > code compatibility is concerned, I don't even think we ever broke
    > compatibility going forward _on the same API platform_ to any significant
    > degree. So I don't think it is likely we are going to in the future.
    >
    > -Ronald-


    This is was I was addressing. And, as the saying goes, 'past performance
    is not an indication of future returns'. I agree, MS has done a good job at
    keeping old (VB) source code from breaking (.Net version excepted), but
    it seemed to be at the expense of larger runtime files, or dependancies.

    When I started programming (different platform), all I had to distribute was
    the program file. VB3 required one other (vbrunxxx) file, VB4 added OLE
    dependancies, and so forth. It just seems to me that with .Net you get to
    start the cycle over again, and I am wondering if such can't be nipped in the
    bud. IMHO, now's the time to address it, but I may be mistaken....

    Back on topic, if I have understood what you were saying, you are indicating
    that in addition to the reference types already present (self-describing types,
    pointer types, and interface types) you say you can 'easily' add a new type
    that will in effect force a full GC cycle when any 'one' of them goes out of
    scope. I guess I would have to rethink my position, because, if I am not
    mistaken, the developer can already initiate a full GC cycle, if such is required.

    This is similar in useage to the old Open/Close scenareo, in that it is already
    the developers responsibility to properly clean up after himself. What you're
    offering in that new type, is not new functionality, but rather convenience.

    The CLR already has a boat load of classes, I think it would in the best interest
    of all involved to avoid adding more to it, when the developer can already do
    the task with a minimal amount of code. Sure, if some task requires a few
    user classes and a page or two of intense code, then maybe go ahead and
    make it convenient, but if the developer can be shown how to do some task
    in (approx.) 10 lines of code or less, perhaps it would not be a good idea to
    put yet another class (or set of classes) in the CLR.

    I am surprized there isn't more people responding to your question, having
    seen all the screaming and shouting that went on, when lack of DF was first
    brought up here. Perhaps we'll hear from more people, later in the week....

    Stay tuned!
    LFS












  15. #15
    Kathleen Dollard Guest

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

    Larry,

    > This is similar in useage to the old Open/Close scenareo, in that it is

    already
    > the developers responsibility to properly clean up after himself. What

    you're
    > offering in that new type, is not new functionality, but rather

    convenience.
    >
    > The CLR already has a boat load of classes, I think it would in the best

    interest
    > of all involved to avoid adding more to it, when the developer can already

    do
    > the task with a minimal amount of code. Sure, if some task requires a few
    > user classes and a page or two of intense code, then maybe go ahead and
    > make it convenient, but if the developer can be shown how to do some task
    > in (approx.) 10 lines of code or less, perhaps it would not be a good idea

    to
    > put yet another class (or set of classes) in the CLR.


    I completely disagree with this. I see two sets of programmers (or myself in
    two different scenarios). One is a class creator and the other is a class
    user. The class creator must be aware of resource issues. This is
    appropriate and that person needs to be able to control the resources. The
    class user should not need to know anything about where a particular piece
    of data or functionality is coming from. The class user should not have to
    control, and in some cases should not be able to control resources, imo.
    With the current complete lack of DF, this responsibility is forced on the
    class user, it makes no difference whether it is one line of code or 200
    lines of code.

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



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