This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: introduce scoped cleanups
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Wed, 05 Jun 2013 11:44:45 -0600
- Subject: Re: RFC: introduce scoped cleanups
- References: <87li7ohtiu dot fsf at fleche dot redhat dot com> <87ppw8qlgl dot fsf at fleche dot redhat dot com> <20130531061135 dot GA12363 at adacore dot com> <87obbrp2hg dot fsf at fleche dot redhat dot com> <51A8CC81 dot 9070509 at redhat dot com> <8738t2q4o2 dot fsf at fleche dot redhat dot com> <20130603060716 dot GC12363 at adacore dot com>
Joel> A very valid concern, IMO! I've never seen heap allocation as
Joel> a reason for concern with respect to performance, and thus have
Joel> never hesitated calling malloc. The only reason I have prefered
Joel> alloca whenever possible is that it allows me to be lazy :-)!
It doesn't happen much, but you can see a few spots where someone coded
around the malloc call -- the various conditional cleanups that my
series removed.
Joel> But this made me realize something: Why would someone want to do
Joel> stack-cleanups instead of just calling alloca directly? Since
Joel> alloca is basically a call-and-forget, what's the advantage of
Joel> going through a stack-based cleanup?
It is the difference between running the cleanup and freeing the memory
that is used by the cleanup object itself.
Joel> Regardless of the above, I like the idea of performing the cleanups
Joel> on an obstack; fast and yet a little more resilient to programming
Joel> errors. Not sure if that would be something easy to implement or not,
Joel> though.
It ought to be easy. I will look into it.
Tom