Garbage collection

Discussion in 'C Programming' started by jacob navia, Apr 25, 2008.

  1. jacob navia

    jacob navia Guest

    In an interviw with Dr Dobbs, Paul Jansen explains which languages are
    gaining in popularity and which not:

    <quote>
    DDJ: Which languages seem to be losing ground?

    PJ: C and C++ are definitely losing ground. There is a simple
    explanation for this. Languages without automated garbage collection are
    getting out of fashion. The chance of running into all kinds of memory
    problems is gradually outweighing the performance penalty you have to
    pay for garbage collection.
    <end quote>

    lcc-win has been distributing a GC since 2004.

    It really helps.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Apr 25, 2008
    #1
    1. Advertising

  2. jacob navia

    cr88192 Guest

    "jacob navia" <> wrote in message
    news:fusi33$e0n$...
    >
    > In an interviw with Dr Dobbs, Paul Jansen explains which languages are
    > gaining in popularity and which not:
    >
    > <quote>
    > DDJ: Which languages seem to be losing ground?
    >
    > PJ: C and C++ are definitely losing ground. There is a simple explanation
    > for this. Languages without automated garbage collection are getting out
    > of fashion. The chance of running into all kinds of memory problems is
    > gradually outweighing the performance penalty you have to pay for garbage
    > collection.
    > <end quote>
    >
    > lcc-win has been distributing a GC since 2004.
    >
    > It really helps.
    >


    I agree...

    I have also been using garbage collection in my projects for years with good
    success...
    I also face people who condemn both garbage collection and C, but I really
    like C personally (I am less of a fan of Java personally, even if it has
    gained a lot of ground...).

    C# may also become a big player, and may in time overpower Java (there are
    variables though, I suspect .NET being both a gain and a potential
    hinderance at this point in time).

    C will likely remain around for a while, but the high-point for C++ may be
    starting to pass (C++ is a heavy beast, and losing some of its major selling
    points to other languages, may start to fall into disuse much faster than C
    does...).


    >
    > --
    > jacob navia
    > jacob at jacob point remcomp point fr
    > logiciels/informatique
    > http://www.cs.virginia.edu/~lcc-win32
     
    cr88192, Apr 25, 2008
    #2
    1. Advertising

  3. jacob navia

    Yunzhong Guest

    I don't see C dying out any time soon. The problem with automatic
    garbage collection is not just in performance penalty, but that it
    introduces uncertainty to the code. It becomes difficult to predict at
    what time the garbage collector will start running. In some cases this
    behavior simply cannot be tolerated.
     
    Yunzhong, Apr 25, 2008
    #3
  4. jacob navia

    jacob navia Guest

    Yunzhong wrote:
    > I don't see C dying out any time soon. The problem with automatic
    > garbage collection is not just in performance penalty, but that it
    > introduces uncertainty to the code. It becomes difficult to predict at
    > what time the garbage collector will start running. In some cases this
    > behavior simply cannot be tolerated.


    In Boehm's GC it will start ONLY when you call malloc().
    If you do not call malloc() nothing can happen...


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Apr 25, 2008
    #4
  5. jacob navia

    user923005 Guest

    On Apr 25, 5:16 am, jacob navia <> wrote:
    > In an interviw with Dr Dobbs, Paul Jansen explains which languages are
    > gaining in popularity and which not:


    Who's Paul Jansen?

    > <quote>
    > DDJ: Which languages seem to be losing ground?
    >
    > PJ: C and C++ are definitely losing ground. There is a simple
    > explanation for this. Languages without automated garbage collection are
    > getting out of fashion. The chance of running into all kinds of memory
    > problems is gradually outweighing the performance penalty you have to
    > pay for garbage collection.
    > <end quote>
    >
    > lcc-win has been distributing a GC since 2004.
    >
    > It really helps.


    Is lcc-win outselling Microsoft or Intel's compilers?

    I guess that most C work is at the embedded level today. I doubt if
    we will have garbage collectors running in our toasters any time soon.
     
    user923005, Apr 25, 2008
    #5
  6. jacob navia

    Richard Guest

    Eric Sosman <> writes:

    >> I guess that most C work is at the embedded level today. I doubt if
    >> we will have garbage collectors running in our toasters any time soon.

    >
    > That's why the toast crumbs keep accumulating at the bottom.


    Heh. That's funny - no garbage collection. Good one.
     
    Richard, Apr 25, 2008
    #6
  7. jacob navia

    santosh Guest

    Gordon Burditt wrote:

    >>lcc-win has been distributing a GC since 2004.
    >>
    >>It really helps.

    >
    > In what ways does that implementation violate the standard?
    >
    > My bet is that it will incorrectly free pieces of allocated memory
    > when the only references to that memory are in a file (written by
    > that process and later read back in by the same process). If lcc-win
    > actually handles this, its performance likely sucks if it has to
    > scan gigabyte (or worse, terabyte) files for pointer references.
    > I think the standard also allows, under the right circumstances,
    > for pointers to be *encrypted*, then stored in a file, and later
    > read back, decrypted, and used.
    >
    > Oh, yes, to count as GC, it has to occasionally actually free
    > something eligible to be freed.
    >
    > I don't consider this to be a fatal flaw for GC in general or this
    > implementation in particular, as storing pointers in files is
    > relatively unusual. But a standards-compliant GC has to deal with
    > it.


    As GC hasn't been defined by the standard yet, we can't say. For all we
    know WG14 might decide to excuse GC from scanning for pointers in files
    and similar stuff. Right now using a GC is non-conforming simply
    because the standard attempts no definition for it.
     
    santosh, Apr 25, 2008
    #7
  8. santosh <> writes:
    > Gordon Burditt wrote:
    >> jacob navia wrote (and Gordon Burditt rudely snipped the attribution):
    >>>lcc-win has been distributing a GC since 2004.
    >>>
    >>>It really helps.

    >>
    >> In what ways does that implementation violate the standard?
    >>
    >> My bet is that it will incorrectly free pieces of allocated memory
    >> when the only references to that memory are in a file (written by
    >> that process and later read back in by the same process). If lcc-win
    >> actually handles this, its performance likely sucks if it has to
    >> scan gigabyte (or worse, terabyte) files for pointer references.
    >> I think the standard also allows, under the right circumstances,
    >> for pointers to be *encrypted*, then stored in a file, and later
    >> read back, decrypted, and used.
    >>
    >> Oh, yes, to count as GC, it has to occasionally actually free
    >> something eligible to be freed.
    >>
    >> I don't consider this to be a fatal flaw for GC in general or this
    >> implementation in particular, as storing pointers in files is
    >> relatively unusual. But a standards-compliant GC has to deal with
    >> it.

    >
    > As GC hasn't been defined by the standard yet, we can't say. For all we
    > know WG14 might decide to excuse GC from scanning for pointers in files
    > and similar stuff. Right now using a GC is non-conforming simply
    > because the standard attempts no definition for it.


    But a given GC implementation might cause a C implementation that uses
    it to become non-conforming because it causes that implementation to
    violate the requirements that the standard *does* define.

    For example, it's perfectly legal to take a pointer object, break its
    representation down into bytes, and store those bytes separately, then
    erase the pointer object's value. You can later reconstitute the
    pointer value from the bytes and use it. A typical GC implementation,
    such as Boehm's, will detect that there is no pointer currently in
    memory that refers to the referenced block of memory, and collect it.

    I'm not claiming that that this is an insurmountable problem. You're
    free to use an almost-but-not-quite-conforming C implementation if
    it's useful to do so, and if the actions that would expose the
    nonconformance are rare and easy to avoid. And if GC were
    incorporated into a future C standard, the rules would probably be
    changed to allow for this kind of thing (by rendering the behavior of
    breaking down and reconstituting a pointer like this undefined), at
    least in programs for which GC is enabled.

    (I do not give permission to quote this article, or any other article
    I post to Usenet, without attribution.)

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Apr 25, 2008
    #8
  9. "Chris Thomasson" <> writes:
    > "jacob navia" <> wrote in message
    > news:fusi33$e0n$...
    >>
    >> In an interviw with Dr Dobbs, Paul Jansen explains which languages
    >> are gaining in popularity and which not:
    >>
    >> <quote>
    >> DDJ: Which languages seem to be losing ground?
    >>
    >> PJ: C and C++ are definitely losing ground. There is a simple
    >> explanation for this. Languages without automated garbage collection
    >> are getting out of fashion. The chance of running into all kinds of
    >> memory problems is gradually outweighing the performance penalty you
    >> have to pay for garbage collection.
    >> <end quote>
    >>
    >> lcc-win has been distributing a GC since 2004.
    >>
    >> It really helps.

    >
    > If you need GC, well yes, it would help out a whole lot indeed. As
    > long as its not mandatory, I see absolutely nothing wrong with
    > including a full-blown GC in your compiler package.


    I also see nothing wrong with it. However, users need to be aware
    that if they write code that depends on GC, they're going to have
    problems if they want to use it with an implementation that doesn't
    support GC. This is a problem with any extension, no matter how
    useful.

    (I think it's possible to use the Boehm GC with other compilers. I
    don't know how difficult it is.)

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Apr 25, 2008
    #9
  10. jacob navia

    jacob navia Guest

    Keith Thompson wrote:
    > But a given GC implementation might cause a C implementation that uses
    > it to become non-conforming because it causes that implementation to
    > violate the requirements that the standard *does* define.
    >
    > For example, it's perfectly legal to take a pointer object, break its
    > representation down into bytes, and store those bytes separately, then
    > erase the pointer object's value. You can later reconstitute the
    > pointer value from the bytes and use it. A typical GC implementation,
    > such as Boehm's, will detect that there is no pointer currently in
    > memory that refers to the referenced block of memory, and collect it.
    >


    Then, there is only ONE solution for you and all people like you:

    DO NOT USE A GC.

    Then, you will happily be able to xor your pointers, store it in files,
    whatever.

    For the other people that do care about memory management, they can go
    on using the GC.

    The only reaction from the "regulars" are this kind of very practical
    arguments.

    Nobody is forbidding anyone to store pointers in files. You can't store
    only those that the GC uses. Other pointers can be stored in files
    at will, since malloc is still available!

    This is typical of their arguments: No substance, just form. There
    could be a pointer stored in a file and the standard says at paragraph
    blah... blah... blah...

    The practical advantages of a GC for a programming language, the pros
    and cons... they do not care


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Apr 25, 2008
    #10
  11. In article <futh8h$cp7$>, jacob navia <> wrote:

    >> But a given GC implementation might cause a C implementation that uses
    >> it to become non-conforming because it causes that implementation to
    >> violate the requirements that the standard *does* define.


    >Then, there is only ONE solution for you and all people like you:
    >
    >DO NOT USE A GC.
    >
    >Then, you will happily be able to xor your pointers, store it in files,
    >whatever.
    >
    >For the other people that do care about memory management, they can go
    >on using the GC.


    Be reasonable Jacob. You deleted the rest of Keith's article, where
    he essentially agrees with you that this problem could be overcome
    by changing C's rules when GC is enabled. You could perfectly well
    have followed up with more discussion of this without flaming him.

    -- Richard
    --
    :wq
     
    Richard Tobin, Apr 25, 2008
    #11
  12. jacob navia

    Paul Hsieh Guest

    On Apr 25, 5:16 am, jacob navia <> wrote:
    > In an interviw with Dr Dobbs, Paul Jansen explains which languages are
    > gaining in popularity and which not:
    >
    > <quote>
    > DDJ: Which languages seem to be losing ground?
    >
    > PJ: C and C++ are definitely losing ground. There is a simple
    > explanation for this. Languages without automated garbage collection are
    > getting out of fashion. The chance of running into all kinds of memory
    > problems is gradually outweighing the performance penalty you have to
    > pay for garbage collection.
    > <end quote>
    >
    > lcc-win has been distributing a GC since 2004.
    >
    > It really helps.


    While I understand what you are doing, it always saddens me that we
    are presented with this false dichotomy. Either we have this painful
    C interface which is precise and fast, but dangerous and cumbersome or
    we have garbage collection which is slow and opaque, but safe and
    easy.

    GC has the disadvantage that you don't *know* when you are going to
    free your memory. In C we have the disadvantage that we don't *know*
    what memory we have outstanding/available except by working it out
    from the model of our program. C++ helps a little with the RAII
    concept, but you can still leak quite easily (and in ways that are
    insanely hard to debug.)

    If C was merely augmented with total memory consumption statistic
    functions and/or heap walking mechanisms and heap checking, all the
    main complaints about C's memory management problems would be
    immediately addressed. The language itself would then be useful in
    discovering problems in code -- even the most complicated structures
    would be fairly approachable, because the ability to debug would
    always be present.

    Alas people don't see it that way. The problem is that people who
    remain loyal to C are too quick to defend C's method without even
    acknowledging its weaknesses. They are essentially arguing that in
    order to support better memory management, you have to go to garbage
    collection and give up the rest of the C language while you are at
    it. Its just so infuriating to me.

    "Why not have GC and malloc/free at the same time" is at least an
    acknowledgment that there are other ways of addressing the issue. The
    way people obsess over the fact that its impossible to do perfect GC
    in C due to some strange pointer obfuscation issue is so telling of
    how badly these people miss the point (the chances that you mess up
    your memory management in your code is enormously higher than the
    chances that you would even consider putting pointer obfuscation in
    your program design).

    I personally would prefer to go in the direction of improving the
    precise memory control model myself. But the ultimate solution (which
    may be too hard to implement; I don't know) is to have an augmented
    precise memory control interface *in addition* to a directly
    compatible GC system (i.e., you would need to support realloc() and
    free() on the GC allocated memory in a meaningful way.) A system like
    that would offer such an enormous value add; but I don't know that it
    could be adopted by the standards committee.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    Paul Hsieh, Apr 25, 2008
    #12
  13. jacob navia <> writes:
    > Keith Thompson wrote:
    >> But a given GC implementation might cause a C implementation that uses
    >> it to become non-conforming because it causes that implementation to
    >> violate the requirements that the standard *does* define.
    >>
    >> For example, it's perfectly legal to take a pointer object, break its
    >> representation down into bytes, and store those bytes separately, then
    >> erase the pointer object's value. You can later reconstitute the
    >> pointer value from the bytes and use it. A typical GC implementation,
    >> such as Boehm's, will detect that there is no pointer currently in
    >> memory that refers to the referenced block of memory, and collect it.
    >>

    >
    > Then, there is only ONE solution for you and all people like you:
    >
    > DO NOT USE A GC.
    >
    > Then, you will happily be able to xor your pointers, store it in files,
    > whatever.
    >
    > For the other people that do care about memory management, they can go
    > on using the GC.
    >
    > The only reaction from the "regulars" are this kind of very practical
    > arguments.
    >
    > Nobody is forbidding anyone to store pointers in files. You can't store
    > only those that the GC uses. Other pointers can be stored in files
    > at will, since malloc is still available!
    >
    > This is typical of their arguments: No substance, just form. There
    > could be a pointer stored in a file and the standard says at paragraph
    > blah... blah... blah...
    >
    > The practical advantages of a GC for a programming language, the pros
    > and cons... they do not care


    jacob, I can only assume that you didn't bother to read what I
    actually wrote before you responded.

    I did not argue against GC. I pointed out a possible problem that
    might be associated with the use of GC, particularly in the context of
    conformance to the C standard.

    Here's part of what I wrote that you didn't quote in your followup:

    | I'm not claiming that that this is an insurmountable problem. You're
    | free to use an almost-but-not-quite-conforming C implementation if
    | it's useful to do so, and if the actions that would expose the
    | nonconformance are rare and easy to avoid. And if GC were
    | incorporated into a future C standard, the rules would probably be
    | changed to allow for this kind of thing (by rendering the behavior of
    | breaking down and reconstituting a pointer like this undefined), at
    | least in programs for which GC is enabled.

    The C standard was not written with GC in mind. You might want to
    argue that it should have been, or that it should be modified so that
    it allows for GC, but it's a fact that the current standard doesn't
    allow for GC. Because of this, it's not at all surprising that there
    might be some corner cases where GC and C standard conformance might
    collide.

    I pointed out a *minor* issue that *might* cause a problem in some
    rare cases. I also mentioned how to avoid that issue. And somehow
    you interpreted this as an attack on GC and/or on you personally.

    I. Did. Not. Argue. Against. GC.

    Please re-read what I actually wrote however many times it takes until
    you understand this.

    I use languages other than C that depend on built-in garbage
    collection, and it's extremely useful. I haven't had an opportunity
    to use a C implementation that provides GC, so I can't really comment
    on how useful it would be in that context.

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Apr 25, 2008
    #13
  14. jacob navia

    Flash Gordon Guest

    William Ahern wrote, On 25/04/08 20:33:
    > user923005 <> wrote:
    >> On Apr 25, 5:16?am, jacob navia <> wrote:
    >>> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
    >>> gaining in popularity and which not:

    >
    >> Who's Paul Jansen?

    >
    >>> <quote>
    >>> DDJ: Which languages seem to be losing ground?
    >>>
    >>> PJ: C and C++ are definitely losing ground. There is a simple
    >>> explanation for this. Languages without automated garbage collection are
    >>> getting out of fashion. The chance of running into all kinds of memory
    >>> problems is gradually outweighing the performance penalty you have to
    >>> pay for garbage collection.
    >>> <end quote>
    >>>
    >>> lcc-win has been distributing a GC since 2004.
    >>>
    >>> It really helps.

    >> Is lcc-win outselling Microsoft or Intel's compilers?
    >>
    >> I guess that most C work is at the embedded level today. I doubt if
    >> we will have garbage collectors running in our toasters any time soon.

    >
    > When people merely say "embedded", I think it confuses the issue.


    True and not just for the reasons you give. Sometimes an "embedded"
    processor turns out to be a full blown computer running either Linux or
    some version of Windows.

    > The places where C continues to be used, and will continue to be used, are
    > places where the problem is very well defined, and the solution amenable to
    > a fixed interface. This happens to be the case for embedded hardware
    > products, as well as for many elements of more general purpose computing
    > platforms: SQL databases, libraries or applications implementing


    <snip>

    > And I think that when people characterize the C community as "mostly
    > embedded developers", they fall into the trap of excusing or explaining a
    > supposed shift; but I don't see a shift in C usage much at all.


    There are also applications which are currently written in C where as
    bits need to be updated they are replaced with code written in other
    languages. Thus in at least some areas (at the very least in some
    companies) the number of lines of C code being used is decreasing as an
    absolute not just relative amount.

    <snip>

    > All that's happening is that there are myriad new _types_ of applications,
    > many of which C is not well suited for. The old _types_ are still there, and
    > usage is growing in absolute terms. There's no need for a bunker mentality.


    I agree there is no need for a bunker mentality. Other languages which
    are older than me are still alive and well (even if not used as much)
    and I'm sure that there will be enough C work around to keep all those
    who both want to be C programmers and have the aptitude/attitude to be C
    programmers busy for a long time to come.
    --
    Flash Gordon
     
    Flash Gordon, Apr 25, 2008
    #14
  15. jacob navia

    jacob navia Guest

    Paul Hsieh wrote:
    > On Apr 25, 5:16 am, jacob navia <> wrote:
    >> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
    >> gaining in popularity and which not:
    >>
    >> <quote>
    >> DDJ: Which languages seem to be losing ground?
    >>
    >> PJ: C and C++ are definitely losing ground. There is a simple
    >> explanation for this. Languages without automated garbage collection are
    >> getting out of fashion. The chance of running into all kinds of memory
    >> problems is gradually outweighing the performance penalty you have to
    >> pay for garbage collection.
    >> <end quote>
    >>
    >> lcc-win has been distributing a GC since 2004.
    >>
    >> It really helps.

    >
    > While I understand what you are doing, it always saddens me that we
    > are presented with this false dichotomy. Either we have this painful
    > C interface which is precise and fast, but dangerous and cumbersome or
    > we have garbage collection which is slow and opaque, but safe and
    > easy.
    >


    Surely my intention wasn't to make an alternative out of GC or
    not GC! There are many other possibilities.


    > GC has the disadvantage that you don't *know* when you are going to
    > free your memory.


    I see it precisely as an advantage. I do not know and I do not want
    to know it precisely. I want that the machine keeps track of it and
    not me. In *some* cases you want to know when you free it, for instance
    if you have allocated a huge block and want to release it immediately to
    avoid a GC. In that cases you call GC_free() that releases the memory
    block immediately.


    In C we have the disadvantage that we don't *know*
    > what memory we have outstanding/available except by working it out
    > from the model of our program. C++ helps a little with the RAII
    > concept, but you can still leak quite easily (and in ways that are
    > insanely hard to debug.)
    >


    Like all C++ :)


    > If C was merely augmented with total memory consumption statistic
    > functions and/or heap walking mechanisms and heap checking, all the
    > main complaints about C's memory management problems would be
    > immediately addressed. The language itself would then be useful in
    > discovering problems in code -- even the most complicated structures
    > would be fairly approachable, because the ability to debug would
    > always be present.
    >


    C programmers do not need debuggers and can debug programs by phone
    without the source.

    Dixit...

    This attitude about debugging (debugging is only for stupid people that
    have bugs. I do not have any bugs since I am the best programmer in the
    world) permeates all the philosophy of the language, and memory
    management is no exception.

    No care is given to the debugging features of malloc/free at all.


    > Alas people don't see it that way. The problem is that people who
    > remain loyal to C are too quick to defend C's method without even
    > acknowledging its weaknesses.


    My language right or wrong!


    > They are essentially arguing that in
    > order to support better memory management, you have to go to garbage
    > collection and give up the rest of the C language while you are at
    > it. Its just so infuriating to me.
    >


    GC is one solution. Your proposal would be another. I do not see why you
    think it is an either/or thing.

    > "Why not have GC and malloc/free at the same time" is at least an
    > acknowledgment that there are other ways of addressing the issue.


    The malloc/free system is still there of course!

    > I personally would prefer to go in the direction of improving the
    > precise memory control model myself. But the ultimate solution (which
    > may be too hard to implement; I don't know) is to have an augmented
    > precise memory control interface *in addition* to a directly
    > compatible GC system (i.e., you would need to support realloc() and
    > free() on the GC allocated memory in a meaningful way.) A system like
    > that would offer such an enormous value add; but I don't know that it
    > could be adopted by the standards committee.
    >


    I can't implement that. I do not have the time. If there was an effort
    where I could collaborate I would, but I can't do it alone.


    > --
    > Paul Hsieh
    > http://www.pobox.com/~qed/
    > http://bstring.sf.net/



    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Apr 25, 2008
    #15
  16. jacob navia

    jacob navia Guest

    Keith Thompson wrote:
    >
    > I did not argue against GC. I pointed out a possible problem that
    > might be associated with the use of GC, particularly in the context of
    > conformance to the C standard.
    >


    Please, that stuff appears every time I mention the GC here.

    "I *could* store pointers in disk and read it later, so the GC
    is not conforming"

    You know that this has no practical significance at all. Since a
    conforming program that stores pointers in the disk is using
    malloc/free and that system is still available, those programs
    would CONTINUE TO RUN!

    The only case where the program would NOT run is if they use the GC
    allocated pointers and put them in the disk!


    But this is the same as saying that

    I stored the socket descriptor in the disk and then, next day, when I
    turned on the machine the network connection would not work...

    Don't you think that it would be much more substantial to address the
    issues that the GC poses in a substantive way?

    Or the issues about the debugging support that Paul Hsie proposes?

    That would be more interesting that the ethernal "GC-and-storing
    pointers in the disk" discussion!

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Apr 25, 2008
    #16
  17. jacob navia

    cr88192 Guest

    "Yunzhong" <> wrote in message
    news:...
    >I don't see C dying out any time soon. The problem with automatic
    > garbage collection is not just in performance penalty, but that it
    > introduces uncertainty to the code. It becomes difficult to predict at
    > what time the garbage collector will start running. In some cases this
    > behavior simply cannot be tolerated.


    I wasn't saying it would die out "soon". what I wrote about could easily
    take 10 or 15 years to play out at the current rates...


    but, my speculation is like this:
    C will fall out of favor for mainstream app development (it already largely
    has), but will likely retain a stronghold in low-level systems, namely:
    embedded systems, OS-kernels, drivers, domain-specific languages (ok, likely
    C-variants), libraries, VMs, ...

    meanwhile, C++ is currently at its high-point, and I will guess will start
    to decline at a faster rate than C (in 15 years, it may have largely fallen
    into disuse). a partial reason for this being a "high cost of maintainence"
    (for both code and implementations, the language less likely to overtake C's
    strongholds, it falls into decline).

    Java is likely to overtake C++, and for a while become the dominant language
    for app development.


    C# is likely to grow at a faster rate than Java, at some point (say, 5-10
    years) overtaking both, however. in this time, to make a guess, .NET will
    either be abandoned or heavily mutated (for example, .GNU, which in time may
    likely mutate in a divergent path).

    at the current rates, in this time period, Windows will also fall behind,
    with most likely the mainstream OS being Linux (thus, C# would become the
    dominant language, on Linux...).

    however, this is predicated on the language and apps being able to
    effectively make the transition (the fall of Windows majorly hurting, but
    not likely killing, the language).


    and in the course of all this, new languages emerge that further begin to
    overtake the current generation (IMO, there will never be an "ultimate
    language", only new ones, most changing what they will, but otherwise being
    very conservative).

    the mainstream language in 20 years could very well by a hybrid of C#,
    JavaScript, and features from many other languages...

    by this time, I also expect notable mutations in terms of kernel
    architecture and filesystems, us likely facing the demise of both processes
    and heirarchical filesystems... Linux either facing replacement, or being
    internally restructured into something almost unrecognizable...

    and so on...


    as noted, this is mostly all just speculation here...
     
    cr88192, Apr 25, 2008
    #17
  18. jacob navia

    user923005 Guest

    On Apr 25, 3:34 pm, "cr88192" <> wrote:
    > "Yunzhong" <> wrote in message
    >
    > news:...
    >
    > >I don't see C dying out any time soon. The problem with automatic
    > > garbage collection is not just in performance penalty, but that it
    > > introduces uncertainty to the code. It becomes difficult to predict at
    > > what time the garbage collector will start running. In some cases this
    > > behavior simply cannot be tolerated.

    >
    > I wasn't saying it would die out "soon". what I wrote about could easily
    > take 10 or 15 years to play out at the current rates...
    >
    > but, my speculation is like this:
    > C will fall out of favor for mainstream app development (it already largely
    > has), but will likely retain a stronghold in low-level systems, namely:
    > embedded systems, OS-kernels, drivers, domain-specific languages (ok, likely
    > C-variants), libraries, VMs, ...
    >
    > meanwhile, C++ is currently at its high-point, and I will guess will start
    > to decline at a faster rate than C (in 15 years, it may have largely fallen
    > into disuse). a partial reason for this being a "high cost of maintainence"
    > (for both code and implementations, the language less likely to overtake C's
    > strongholds, it falls into decline).
    >
    > Java is likely to overtake C++, and for a while become the dominant language
    > for app development.
    >
    > C# is likely to grow at a faster rate than Java, at some point (say, 5-10
    > years) overtaking both, however. in this time, to make a guess, .NET will
    > either be abandoned or heavily mutated (for example, .GNU, which in time may
    > likely mutate in a divergent path).
    >
    > at the current rates, in this time period, Windows will also fall behind,
    > with most likely the mainstream OS being Linux (thus, C# would become the
    > dominant language, on Linux...).
    >
    > however, this is predicated on the language and apps being able to
    > effectively make the transition (the fall of Windows majorly hurting, but
    > not likely killing, the language).
    >
    > and in the course of all this, new languages emerge that further begin to
    > overtake the current generation (IMO, there will never be an "ultimate
    > language", only new ones, most changing what they will, but otherwise being
    > very conservative).
    >
    > the mainstream language in 20 years could very well by a hybrid of C#,
    > JavaScript, and features from many other languages...
    >
    > by this time, I also expect notable mutations in terms of kernel
    > architecture and filesystems, us likely facing the demise of both processes
    > and heirarchical filesystems... Linux either facing replacement, or being
    > internally restructured into something almost unrecognizable...
    >
    > and so on...
    >
    > as noted, this is mostly all just speculation here...


    Looking at the past is always easy.
    Prophecy proves more difficult.
     
    user923005, Apr 25, 2008
    #18
  19. jacob navia

    Bartc Guest

    "Eric Sosman" <> wrote in message
    news:1209149152.181452@news1nwk...
    > user923005 wrote:



    >> I guess that most C work is at the embedded level today. I doubt if
    >> we will have garbage collectors running in our toasters any time soon.

    >
    > That's why the toast crumbs keep accumulating at the bottom.


    There might be a little tray that you can slide out to remove the crumbs
    easily.

    --
    Bart
     
    Bartc, Apr 26, 2008
    #19
  20. jacob navia

    Bartc Guest

    "jacob navia" <> wrote in message
    news:fusi33$e0n$...
    >
    > In an interviw with Dr Dobbs, Paul Jansen explains which languages are
    > gaining in popularity and which not:
    >
    > <quote>
    > DDJ: Which languages seem to be losing ground?
    >
    > PJ: C and C++ are definitely losing ground. There is a simple explanation
    > for this. Languages without automated garbage collection are getting out
    > of fashion. The chance of running into all kinds of memory problems is
    > gradually outweighing the performance penalty you have to pay for garbage
    > collection.
    > <end quote>
    >
    > lcc-win has been distributing a GC since 2004.


    I've little idea about GC or how it works (not about strategies and things
    but how it knows what goes on in the program).

    What happens in this code fragment:

    void fn(void) {
    int *p = malloc(1236);
    }

    when p goes out of scope? (Presumably some replacement for malloc() is
    used.)

    What about a linked list when it's no longer needed? How does GC know that,
    do you tell it? And it knows where all the pointers in each node are. I can
    think of a dozen ways to confuse a GC so it all sounds like magic to me, if
    it works.

    --
    Bart
     
    Bartc, Apr 26, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Laser Lu

    Garbage Collection and Manage Code?

    Laser Lu, Jan 26, 2004, in forum: ASP .Net
    Replies:
    5
    Views:
    731
    Gaurav Khanna [C# MVP]
    Jan 27, 2004
  2. Cheung, Jeffrey Jing-Yen
    Replies:
    3
    Views:
    1,562
    Cheung, Jeffrey Jing-Yen
    Jul 10, 2003
  3. IDoNothing

    Garbage Collection in ASP.NET

    IDoNothing, Jan 9, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    8,384
    cjohn
    Aug 20, 2009
  4. Replies:
    1
    Views:
    451
    mrstephengross
    Jul 25, 2005
  5. Øyvind Isaksen
    Replies:
    1
    Views:
    998
    Øyvind Isaksen
    May 18, 2007
Loading...

Share This Page