Garbage collector in Standard C++?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 24

Thread: Garbage collector in Standard C++?

  1. #1
    Erin Gannon Guest

    Garbage collector in Standard C++?


    Would you like to see a garbage collector becoming an integral feature of
    standard C++? How will this feature effect your design and implementation?
    What kind of impact will it have on debugging and testing?

    Erin Gannon
    Associate Editor
    DevX.com, Inc.
    eganon@devx.com

  2. #2
    ralph Guest

    Re: Garbage collector in Standard C++?


    "Erin Gannon" <egannon@devx.com> wrote:
    >
    >Would you like to see a garbage collector becoming an integral feature of
    >standard C++?
    > ...


    No.

    > ...
    >How will this feature effect your design and implementation?
    >What kind of impact will it have on debugging and testing?
    > ...


    To ridiculous to waste time on considering an answer.

    >Erin Gannon
    >Associate Editor
    >DevX.com, Inc.
    >eganon@devx.com



    Garbage Collection has always been some kind of Holy Grail for seqments of
    every programming community. It is like the plea for email for some dying
    child - It keeps popping up every now and then. To a fresh audience, who
    get taken in, totally unaware of what a cruel joke it really is.

    Stripped of all the hype, Garbage Collection is nothing more than giving
    up the control of the lifecycle of your objects to a "behind the scenes"
    Memory Manager. We can all sit around and come-up with some grand scheme
    of how we would like this faithful servant to work. And probably successfully
    sell the idea to a few of our more gullible associates. Implementing it would
    be another story. Malloc() and the VMM of any existing operating system is
    a perfect example. We have had over 30+ years to chew on them and they are
    still only a "best fit" to handle the majority of cases.

    Sure it would be nice to never have to think about calling "delete []" again,
    but the trade-off of becoming totally dependent on a "one-size-fits-all"
    solution is not worth it and patently silly for a serious robust flexible
    language.

    Let those, who desire Wal-Mart-brand good-enough software, to go ahead and
    migrate to Visual Basic, C#, and <fill_in_the_blank> languages. That is why
    those languages exist and why they are so appealing. Let those who still
    desire to write quality software have a tool to do it. A tool unfettered
    by some starry-eyed committee's opinion of how it "ought to be", but lean
    and trim and ready to provide solutions that "need to be".

    -ralph


  3. #3
    Danny Kalev Guest

    Re: Garbage collector in Standard C++?



    ralph wrote:
    >
    > "Erin Gannon" <egannon@devx.com> wrote:
    > >
    > >Would you like to see a garbage collector becoming an integral feature of
    > >standard C++?
    > > ...

    >
    > No.
    >
    > > ...
    > >How will this feature effect your design and implementation?
    > >What kind of impact will it have on debugging and testing?
    > > ...

    >
    > To ridiculous to waste time on considering an answer.
    >
    > >Erin Gannon
    > >Associate Editor
    > >DevX.com, Inc.
    > >eganon@devx.com

    >
    > Garbage Collection has always been some kind of Holy Grail for seqments of
    > every programming community. It is like the plea for email for some dying
    > child - It keeps popping up every now and then. To a fresh audience, who
    > get taken in, totally unaware of what a cruel joke it really is.
    >
    > Stripped of all the hype, Garbage Collection is nothing more than giving
    > up the control of the lifecycle of your objects to a "behind the scenes"
    > Memory Manager. We can all sit around and come-up with some grand scheme
    > of how we would like this faithful servant to work. And probably successfully
    > sell the idea to a few of our more gullible associates. Implementing it would
    > be another story. Malloc() and the VMM of any existing operating system is
    > a perfect example. We have had over 30+ years to chew on them and they are
    > still only a "best fit" to handle the majority of cases.
    >
    > Sure it would be nice to never have to think about calling "delete []" again,
    > but the trade-off of becoming totally dependent on a "one-size-fits-all"
    > solution is not worth it and patently silly for a serious robust flexible
    > language.
    >
    > Let those, who desire Wal-Mart-brand good-enough software, to go ahead and
    > migrate to Visual Basic, C#, and <fill_in_the_blank> languages. That is why
    > those languages exist and why they are so appealing. Let those who still
    > desire to write quality software have a tool to do it. A tool unfettered
    > by some starry-eyed committee's opinion of how it "ought to be", but lean
    > and trim and ready to provide solutions that "need to be".


    while I agree with most of what you say (personally, I've never felt a
    need for having a garbage collector in my apps, especially ever since
    STL and auto_ptr<> were introduced to C++). However, we can't ignore two
    facts: memory management is still a serious stumbling block for
    non-expert programmers and IMO, it's the #1 cause of bugs and
    inefficiencies in C++ code.
    Secondly, there have been proposals to add a garbage collector to C++ in
    the next standard revision. It's too early to tell which type of GC C++
    will have, if it's going to have one at all.

    Danny

  4. #4
    James Lonero Guest

    Re: Garbage collector in Standard C++?


    "Erin Gannon" <egannon@devx.com> wrote:
    >
    >Would you like to see a garbage collector becoming an integral feature of
    >standard C++? How will this feature effect your design and implementation?
    >What kind of impact will it have on debugging and testing?
    >
    >Erin Gannon
    >Associate Editor
    >DevX.com, Inc.
    >eganon@devx.com

    This would be difficult given the current state of C++ memory access.
    It would be nice to have garbage collection, especially for large programs
    that must run long periods of time or run in critical situations. And in
    C++, memory allocation is a MUST. But, one of the problems is that eventually,
    the memory becomes so fragmented, that it can be come impossible to find
    sufficient contigious memory for your request. Then what do we want to do
    with the error condition returned?
    With garbage collection, it could insure against this happening. One
    problem is that it may need to move already allocated memory. Since C and
    C++ directly access memory, this will be a major problem. Some one that
    I used to work with programmed in C/C++ on the Apple MacIntosh and said that
    there, they used pointers to pointers. The C++ pointers didn't directly
    access memory, but pointed to a table entry holding a pointer to memory.
    The compiler made it all invisible to the user. This situation would easily
    allow for garbage collection.
    Because of the current situation with C and C++, I do not think that I
    would want my life to be dependent on a system programmed with C or C++,
    especially if it needs to allocate memory. (Next time you get on an airliner,
    ask what language the flight system was programmed in.)

    Jim L.

  5. #5
    Danny Kalev Guest

    Re: Garbage collector in Standard C++?



    James Lonero wrote:
    >
    > "Erin Gannon" <egannon@devx.com> wrote:
    > >
    > >Would you like to see a garbage collector becoming an integral feature of
    > >standard C++? How will this feature effect your design and implementation?
    > >What kind of impact will it have on debugging and testing?
    > >
    > >Erin Gannon
    > >Associate Editor
    > >DevX.com, Inc.
    > >eganon@devx.com

    > This would be difficult given the current state of C++ memory access.
    > It would be nice to have garbage collection, especially for large programs
    > that must run long periods of time or run in critical situations. And in
    > C++, memory allocation is a MUST.


    Well, is it really so? In my 13 years of so of C/C++ programming, I have
    seen so many code fragments in which memory allocation was outwardly a
    "must" but it could have been easily replaced with higher-level
    constructs such as STL, auto_ptr, or plain and simple stack/static
    memory. (I'm talking about C++, I agree that in C there's really no
    viable alternative to malloc/calloc)

    But, one of the problems is that eventually,
    > the memory becomes so fragmented, that it can be come impossible to find
    > sufficient contigious memory for your request. Then what do we want to do
    > with the error condition returned?


    This is an implementation issue. Clever OSs (without naming names...)
    automatically perform memory compaction -- a process that unites small
    chunks of free memory into a single, contiguous block.

    > With garbage collection, it could insure against this happening. One
    > problem is that it may need to move already allocated memory. Since C and
    > C++ directly access memory, this will be a major problem.


    They don't necessary access direct memory. What is direct memory after
    all? The physical RAM address? All modern OSs nowadays use virtual
    memory systems so what you consider as an address is in fact an alias or
    a reference that the VMM transparently translates to a physical address.
    Adding an extra level of indirection could solve this problem easily.

    Some one that
    > I used to work with programmed in C/C++ on the Apple MacIntosh and said that
    > there, they used pointers to pointers. The C++ pointers didn't directly
    > access memory, but pointed to a table entry holding a pointer to memory.
    > The compiler made it all invisible to the user. This situation would easily
    > allow for garbage collection.
    > Because of the current situation with C and C++, I do not think that I
    > would want my life to be dependent on a system programmed with C or C++,
    > especially if it needs to allocate memory. (Next time you get on an airliner,
    > ask what language the flight system was programmed in.)


    Don't be so surprised if the answer would always be "yes". The only
    three programming languages used in embedded systems these days (and
    please don't pay too much attention the Java hype -- it's practically
    useless in such environments) are assembly, C and C++. I prefer to know
    that a certain device was programmed in C++ rather than assembly, after
    all:)

    Danny

  6. #6
    ralph Guest

    Re: Garbage collector in Standard C++?


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    > ... snipped
    >
    > ...
    >while I agree with most of what you say (personally, I've never felt a
    >need for having a garbage collector in my apps, especially ever since
    >STL and auto_ptr<> were introduced to C++). However, we can't ignore two
    >facts: memory management is still a serious stumbling block for
    >non-expert programmers and IMO, it's the #1 cause of bugs and
    >inefficiencies in C++ code.
    >Secondly, there have been proposals to add a garbage collector to C++ in
    >the next standard revision. It's too early to tell which type of GC C++
    >will have, if it's going to have one at all.
    >
    >Danny


    And I have to agree with what you said about non-expert programmers. I believe
    that is a large part of any movement to adopting garbage collection. I remember
    attending a meeting back in the 80's where everyone was discussing I think
    Object-C <?> and that same argument was raised. The battle-cry - "Its for
    the children"! has always been effective to at least get listeners. <g>

    As far as it being introduced - I guess there is no way to stop it. Certainly
    not by me. Hopefully, however there will be a way to #pragma the sucker away.


    Of course, now that I think about it... I am pretty safe, since I still do
    the bulk of my programming with VC++. It will be at least 2 to 3 years after
    any standard is released before it shows up in a Microsoft compiler. <g>

    -ralph

  7. #7
    Danny Kalev Guest

    Re: Garbage collector in Standard C++?



    ralph wrote:
    > Of course, now that I think about it... I am pretty safe, since I still do
    > the bulk of my programming with VC++. It will be at least 2 to 3 years after
    > any standard is released before it shows up in a Microsoft compiler. <g>


    you're very optimistic, I must say:) If it only took MS 2-3 years to
    comply with standards, VC++ would be the most standard compliant
    compiler in the neighborhood.

    Danny

  8. #8
    ralph Guest

    Re: Garbage collector in Standard C++?


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >ralph wrote:
    >> Of course, now that I think about it... I am pretty safe, since I still

    do
    >> the bulk of my programming with VC++. It will be at least 2 to 3 years

    after
    >> any standard is released before it shows up in a Microsoft compiler. <g>

    >
    >you're very optimistic, I must say:) If it only took MS 2-3 years to
    >comply with standards, VC++ would be the most standard compliant
    >compiler in the neighborhood.
    >
    >Danny


    LOL

    As a side note, now that my ranting is finished, I am kind of curious to
    see how the new "managed code" extensions are going to work out with M$'s
    new .NET release. (I have no problem with a specific memory management system
    tied to an specific framework. I just don't want to see it as part of the
    language.)

    It is the first time I have been seriously exposed to applications that will
    exist in different "memory" models at the same time. Have you had an opportunity
    to play with any of it yet?

    -ralph


  9. #9
    Danny Kalev Guest

    Re: Garbage collector in Standard C++?



    ralph wrote:
    >
    > Danny Kalev <dannykk@inter.net.il> wrote:
    > >
    > >
    > >ralph wrote:
    > >> Of course, now that I think about it... I am pretty safe, since I still

    > do
    > >> the bulk of my programming with VC++. It will be at least 2 to 3 years

    > after
    > >> any standard is released before it shows up in a Microsoft compiler. <g>

    > >
    > >you're very optimistic, I must say:) If it only took MS 2-3 years to
    > >comply with standards, VC++ would be the most standard compliant
    > >compiler in the neighborhood.
    > >
    > >Danny

    >
    > LOL
    >
    > As a side note, now that my ranting is finished, I am kind of curious to
    > see how the new "managed code" extensions are going to work out with M$'s
    > new .NET release. (I have no problem with a specific memory management system
    > tied to an specific framework. I just don't want to see it as part of the
    > language.)
    >
    > It is the first time I have been seriously exposed to applications that will
    > exist in different "memory" models at the same time. Have you had an opportunity
    > to play with any of it yet?


    I haven't but I read a review on DevX. It seems that the managed code
    works in a neat way: you have two types of classes: managed and
    unmanaged. Instances of managed classes are garbage collected; you don't
    delete them explicitly. Objects of unmanaged classes are ordinary C++
    objects that can be allocated on any of the three storage types (auto,
    static and free-store). This way, you have full control over the garbage
    collector. You can disable it altogether simply by not declaring managed
    classes. Another benefit of this approach is backward compatibility with
    legacy/imported code.
    However, if I were to design a garbage collector, I'd use a per-object
    approach rather than a per-class solution.

    Danny

    >
    > -ralph


  10. #10
    cteas Guest

    Re: Garbage collector in Standard C++?


    "James Lonero" <James.lonero@hii-hitachi.com> wrote:
    >
    >"Erin Gannon" <egannon@devx.com> wrote:
    >>
    >>Would you like to see a garbage collector becoming an integral feature

    of
    >>standard C++? How will this feature effect your design and implementation?
    >>What kind of impact will it have on debugging and testing?
    >>
    >>Erin Gannon
    >>Associate Editor
    >>DevX.com, Inc.
    >>eganon@devx.com

    > This would be difficult given the current state of C++ memory access.
    > It would be nice to have garbage collection, especially for large programs
    >that must run long periods of time or run in critical situations. And in
    >C++, memory allocation is a MUST. But, one of the problems is that eventually,
    >the memory becomes so fragmented, that it can be come impossible to find
    >sufficient contigious memory for your request. Then what do we want to

    do
    >with the error condition returned?
    > With garbage collection, it could insure against this happening. One
    >problem is that it may need to move already allocated memory. Since C and
    >C++ directly access memory, this will be a major problem. Some one that
    >I used to work with programmed in C/C++ on the Apple MacIntosh and said

    that
    >there, they used pointers to pointers. The C++ pointers didn't directly
    >access memory, but pointed to a table entry holding a pointer to memory.
    > The compiler made it all invisible to the user. This situation would easily
    >allow for garbage collection.
    > Because of the current situation with C and C++, I do not think that

    I
    >would want my life to be dependent on a system programmed with C or C++,
    >especially if it needs to allocate memory. (Next time you get on an airliner,
    >ask what language the flight system was programmed in.)
    >
    >Jim L.


    Most likely Ada of course. One of its virtues is the excellent garbage collection.


  11. #11
    Danny Kalev Guest

    Re: Garbage collector in Standard C++?



    cteas wrote:
    >
    > "James Lonero" <James.lonero@hii-hitachi.com> wrote:
    > >
    > >"Erin Gannon" <egannon@devx.com> wrote:
    > >>
    > >>Would you like to see a garbage collector becoming an integral feature

    > of
    > >>standard C++? How will this feature effect your design and implementation?
    > >>What kind of impact will it have on debugging and testing?
    > >>
    > >>Erin Gannon
    > >>Associate Editor
    > >>DevX.com, Inc.
    > >>eganon@devx.com

    > > This would be difficult given the current state of C++ memory access.
    > > It would be nice to have garbage collection, especially for large programs
    > >that must run long periods of time or run in critical situations. And in
    > >C++, memory allocation is a MUST. But, one of the problems is that eventually,
    > >the memory becomes so fragmented, that it can be come impossible to find
    > >sufficient contigious memory for your request. Then what do we want to

    > do
    > >with the error condition returned?
    > > With garbage collection, it could insure against this happening. One
    > >problem is that it may need to move already allocated memory. Since C and
    > >C++ directly access memory, this will be a major problem. Some one that
    > >I used to work with programmed in C/C++ on the Apple MacIntosh and said

    > that
    > >there, they used pointers to pointers. The C++ pointers didn't directly
    > >access memory, but pointed to a table entry holding a pointer to memory.
    > > The compiler made it all invisible to the user. This situation would easily
    > >allow for garbage collection.
    > > Because of the current situation with C and C++, I do not think that

    > I
    > >would want my life to be dependent on a system programmed with C or C++,
    > >especially if it needs to allocate memory. (Next time you get on an airliner,
    > >ask what language the flight system was programmed in.)
    > >
    > >Jim L.

    >
    > Most likely Ada of course. One of its virtues is the excellent garbage collection.


    AFAIK, Ada's GC is optional; there is no requirement in the Ada standard
    that an implementation have a GC so in this regard, it isn't very much
    different from C++ -- there are C++ environments that have a GC too.
    Besides, seriously, who's using Ada these days anyway?

    Danny

  12. #12
    cteas Guest

    Re: Garbage collector in Standard C++?


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >cteas wrote:
    >>
    >> "James Lonero" <James.lonero@hii-hitachi.com> wrote:
    >> >
    >> >"Erin Gannon" <egannon@devx.com> wrote:
    >> >>
    >> >>Would you like to see a garbage collector becoming an integral feature

    >> of
    >> >>standard C++? How will this feature effect your design and implementation?
    >> >>What kind of impact will it have on debugging and testing?
    >> >>
    >> >>Erin Gannon
    >> >>Associate Editor
    >> >>DevX.com, Inc.
    >> >>eganon@devx.com
    >> > This would be difficult given the current state of C++ memory access.
    >> > It would be nice to have garbage collection, especially for large programs
    >> >that must run long periods of time or run in critical situations. And

    in
    >> >C++, memory allocation is a MUST. But, one of the problems is that eventually,
    >> >the memory becomes so fragmented, that it can be come impossible to find
    >> >sufficient contigious memory for your request. Then what do we want

    to
    >> do
    >> >with the error condition returned?
    >> > With garbage collection, it could insure against this happening.

    One
    >> >problem is that it may need to move already allocated memory. Since

    C and
    >> >C++ directly access memory, this will be a major problem. Some one that
    >> >I used to work with programmed in C/C++ on the Apple MacIntosh and said

    >> that
    >> >there, they used pointers to pointers. The C++ pointers didn't directly
    >> >access memory, but pointed to a table entry holding a pointer to memory.
    >> > The compiler made it all invisible to the user. This situation would

    easily
    >> >allow for garbage collection.
    >> > Because of the current situation with C and C++, I do not think that

    >> I
    >> >would want my life to be dependent on a system programmed with C or C++,
    >> >especially if it needs to allocate memory. (Next time you get on an

    airliner,
    >> >ask what language the flight system was programmed in.)
    >> >
    >> >Jim L.

    >>
    >> Most likely Ada of course. One of its virtues is the excellent garbage

    collection.
    >
    >AFAIK, Ada's GC is optional; there is no requirement in the Ada standard
    >that an implementation have a GC so in this regard, it isn't very much
    >different from C++ -- there are C++ environments that have a GC too.
    >Besides, seriously, who's using Ada these days anyway?
    >
    >Danny


    That is true, but Ada makes garbage collection easy. It's not my favorite
    tool either, but it is still widely used. All Boeing aircraft, and Airbus
    use Ada for their flight code. The department of defense and all of its contractors
    use it as well. Until 1998, it was mandated by the DOD.

  13. #13
    ch0rlt0n Guest

    Re: Garbage collector in Standard C++?


    I'd like to have the control over when and where my memory is allocated and
    deallocated thank you very much. I don't really think there's much of an
    excuse for memory leaks with modern debugging tools.

    If I'm worried about memory fragmentation then I'll use a pool of pre-allocated
    objects.

    If the lifecycle of objects isn't too important then I might use a library
    that supports GC but I'd hate to see it as a standard part of C++.

    I can't comment on Ada but I'm starting to have a few niggling worries with
    Java, particularly with regard to objects which create and use OS resources
    such as windows handles. These are a finite resource and I'd like to have
    an idea about how many are allocated at any one time.

    I'd also be more than happy to fly using a system coded in C or C++. I might
    think twice if it was in VB :o)

    >>> > Because of the current situation with C and C++, I do not think that
    >>> I
    >>> >would want my life to be dependent on a system programmed with C or

    C++,
    >>> >especially if it needs to allocate memory. (Next time you get on an

    >airliner,
    >>> >ask what language the flight system was programmed in.)
    >>> >
    >>> >Jim L.
    >>>
    >>> Most likely Ada of course. One of its virtues is the excellent garbage

    >collection.
    >>
    >>AFAIK, Ada's GC is optional; there is no requirement in the Ada standard
    >>that an implementation have a GC so in this regard, it isn't very much
    >>different from C++ -- there are C++ environments that have a GC too.
    >>Besides, seriously, who's using Ada these days anyway?
    >>
    >>Danny

    >
    >That is true, but Ada makes garbage collection easy. It's not my favorite
    >tool either, but it is still widely used. All Boeing aircraft, and Airbus
    >use Ada for their flight code. The department of defense and all of its

    contractors
    >use it as well. Until 1998, it was mandated by the DOD.



  14. #14
    Danny Kalev Guest

    Re: Garbage collector in Standard C++?



    cteas wrote:
    >
    > Danny Kalev <dannykk@inter.net.il> wrote:
    > >
    > >
    > >cteas wrote:
    > >>
    > >> "James Lonero" <James.lonero@hii-hitachi.com> wrote:
    > >> >
    > >> >"Erin Gannon" <egannon@devx.com> wrote:
    > >> >>
    > >> >>Would you like to see a garbage collector becoming an integral feature
    > >> of
    > >> >>standard C++? How will this feature effect your design and implementation?
    > >> >>What kind of impact will it have on debugging and testing?
    > >> >>
    > >> >>Erin Gannon
    > >> >>Associate Editor
    > >> >>DevX.com, Inc.
    > >> >>eganon@devx.com
    > >> > This would be difficult given the current state of C++ memory access.
    > >> > It would be nice to have garbage collection, especially for large programs
    > >> >that must run long periods of time or run in critical situations. And

    > in
    > >> >C++, memory allocation is a MUST. But, one of the problems is that eventually,
    > >> >the memory becomes so fragmented, that it can be come impossible to find
    > >> >sufficient contigious memory for your request. Then what do we want

    > to
    > >> do
    > >> >with the error condition returned?
    > >> > With garbage collection, it could insure against this happening.

    > One
    > >> >problem is that it may need to move already allocated memory. Since

    > C and
    > >> >C++ directly access memory, this will be a major problem. Some one that
    > >> >I used to work with programmed in C/C++ on the Apple MacIntosh and said
    > >> that
    > >> >there, they used pointers to pointers. The C++ pointers didn't directly
    > >> >access memory, but pointed to a table entry holding a pointer to memory.
    > >> > The compiler made it all invisible to the user. This situation would

    > easily
    > >> >allow for garbage collection.
    > >> > Because of the current situation with C and C++, I do not think that
    > >> I
    > >> >would want my life to be dependent on a system programmed with C or C++,
    > >> >especially if it needs to allocate memory. (Next time you get on an

    > airliner,
    > >> >ask what language the flight system was programmed in.)
    > >> >
    > >> >Jim L.
    > >>
    > >> Most likely Ada of course. One of its virtues is the excellent garbage

    > collection.
    > >
    > >AFAIK, Ada's GC is optional; there is no requirement in the Ada standard
    > >that an implementation have a GC so in this regard, it isn't very much
    > >different from C++ -- there are C++ environments that have a GC too.
    > >Besides, seriously, who's using Ada these days anyway?
    > >
    > >Danny

    >
    > That is true, but Ada makes garbage collection easy. It's not my favorite
    > tool either, but it is still widely used. All Boeing aircraft, and Airbus
    > use Ada for their flight code. The department of defense and all of its contractors
    > use it as well. Until 1998, it was mandated by the DOD.


    Since you seem to be an experienced Ada programmer, I'd like to hear
    more about its GC. From what I've heard, Ada's GC (in implementations
    that provided it) was too slow and that is why the requirement to make
    it optional came from programmers. The Java hypists claim that they've
    improved the underlying GC algorithm so it is supposedly better than
    old-style GCs (e.g., Ada's). I really can't evaluate these claims
    because I've never used Ada seriously. Btw, what about Ada95?

    Danny

  15. #15
    stewart hall Guest

    Re: Garbage collector in Standard C++?


    Danny Kalev <dannykk@inter.net.il> wrote:
    >Since you seem to be an experienced Ada programmer, I'd like to hear
    >more about its GC. From what I've heard, Ada's GC (in implementations
    >that provided it) was too slow and that is why the requirement to make
    >it optional came from programmers. The Java hypists claim that they've
    >improved the underlying GC algorithm so it is supposedly better than
    >old-style GCs (e.g., Ada's). I really can't evaluate these claims
    >because I've never used Ada seriously. Btw, what about Ada95?
    >
    >Danny



    Hi Danny,

    We never used GC on any of our Ada projects as it was non-standard and we
    considered the whole concept too risky and slow for our critical applications.
    Our own Ada projects avoided dynamic memory allocation.

    In Ada's defence, the language is heavily used in the UK for Defence, Space
    and Safety Critical apps. These sectors represent some of our nations largest
    investors in software. The language was always suited to embedded and critical
    apps but not desktop or HMI heavy ones.

    P.S. thanks for all your C++ hints and tips on DevX, I'm even beginning to
    like the language now!

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