public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Lawrence Crowl <crowl@google.com>
To: weigelt@metux.de, gcc-help@gcc.gnu.org
Subject: Re: C++ and garbage collection
Date: Sat, 05 Feb 2011 04:25:00 -0000	[thread overview]
Message-ID: <AANLkTimjjJd52d6vy7H3+sv4h0Nj_Y-mPHTVnYBUc-b8@mail.gmail.com> (raw)
In-Reply-To: <20110204194604.GB12837@nibiru.local>

On 2/4/11, Enrico Weigelt <weigelt@metux.de> wrote:
> I'm currently working on an complex C++ application (which I, if it
> would have to be rewritten from scratch, would do in Java instead ;-o)
> and I wonder whether it's possible to move to an garbage collection
> in smaller steps. For now there're some parts using some "autopointer"
> class (didn't deeply look into it, but I guess it's overloading
> the pointer operations and doing some reference counting, which
> of course isn't generally complete - would keep ring structures
> forever ;-o).
>
> My idea is to add some mark+sweep gc (boem-gc ?) and remove (or
> somehow disable) all delete operations. Does that work safely,
> or do I have to cope with certain nasty side effects ?

If your problem is leaking memory, and you aren't playing games
with your pointers, then you can just add in the Boehm collector,
leaving the deletes in place.  This approach will leave the program
working pretty much as before, but with less memory.

If your problem is using objects after you have freed them, then you
have a much harder problem.  Many C++ programs do real work in the
destructors (like closing files) and removing the delete operations
would disable that code.  One viable approach is to modify the uses
of pointers into shared_ptr (from TR1 or boost) and then add the
Boehm collector.  This process takes work, because changing all
pointers won't work and changing none won't buy you anything.

-- 
Lawrence Crowl

  parent reply	other threads:[~2011-02-05  0:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-04 20:25 Enrico Weigelt
2011-02-04 22:13 ` Florian Weimer
2011-02-05 12:51   ` Enrico Weigelt
2011-02-05  0:03 ` Jonathan Wakely
2011-02-05  4:25 ` Lawrence Crowl [this message]
2011-02-05 14:37   ` Enrico Weigelt
2011-02-05 14:43     ` Jonathan Wakely
2011-02-05 14:56       ` Enrico Weigelt
2011-02-06 19:29         ` Florian Weimer
2011-02-07  6:41           ` Enrico Weigelt
2011-02-07 18:50             ` Florian Weimer
2011-02-12 20:55               ` Enrico Weigelt
2011-02-06 23:01         ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTimjjJd52d6vy7H3+sv4h0Nj_Y-mPHTVnYBUc-b8@mail.gmail.com \
    --to=crowl@google.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=weigelt@metux.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).