This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: C++ nested classes, namespaces, structs, and compound statements
- From: Dan Kegel <dank at kegel dot com>
- To: Daniel Berlin <dan at dberlin dot org>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, Jim Blandy <jimb at redhat dot com>, gdb at sources dot redhat dot com, Benjamin Kosnik <bkoz at redhat dot com>
- Date: Sat, 06 Apr 2002 07:31:31 -0800
- Subject: Re: C++ nested classes, namespaces, structs, and compound statements
- References: <Pine.LNX.4.44.0204060236110.25262-100000@dberlin.org>
- Reply-to: dank at kegel dot com
Daniel Berlin wrote:
> I can tell you that while I did succeeed in keeping a working gdb at
> all times, even with a mix of new type structures and old (which are
> completely different beasts), it was *amazingly* tedious to do it this
> way.
>
> It's not just a matter of global search and replace, the rewriting
> required is mundane and repetitive, but a step above what simple global
> search and replace would do, so you end up doing it by hand (you'd need
> to write a pass for a source-source translator or something to do it
> automatically).
The 'refactoring' weenies are trying to produce editors that
automate this sort of global search-and-replace. I have not tried
any of them yet. It'd be fairly amazing if they worked well for C++,
let alone C. (See e.g.
http://www.refactoring.com/
http://www.xref-tech.com/speller/
http://www-106.ibm.com/developerworks/linux/library/l-eclipse.html )
> It was at least 2x the work it would have been to not do it incrementally.
> But it's also less disheartening then dealing with 8 million compile
> errors at once, and trying to hunt down logic bugs after making a million
> changes.
Agreed. As time goes on, I find incremental refactoring increasingly
my favorite way to make big changes.
- Dan