From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4645 invoked by alias); 6 Apr 2002 15:18:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4638 invoked from network); 6 Apr 2002 15:18:40 -0000 Received: from unknown (HELO relay.pair.com) (209.68.1.20) by sources.redhat.com with SMTP; 6 Apr 2002 15:18:40 -0000 Received: (qmail 70381 invoked from network); 6 Apr 2002 15:18:39 -0000 Received: from c-24-126-75-99.we.client2.attbi.com (HELO kegel.com) (24.126.75.99) by relay1.pair.com with SMTP; 6 Apr 2002 15:18:39 -0000 X-pair-Authenticated: 24.126.75.99 Message-ID: <3CAF14D3.4A5CF457@kegel.com> Date: Sat, 06 Apr 2002 07:18:00 -0000 From: Dan Kegel Reply-To: dank@kegel.com X-Accept-Language: en MIME-Version: 1.0 To: Daniel Berlin CC: Daniel Jacobowitz , Jim Blandy , gdb@sources.redhat.com, Benjamin Kosnik Subject: Re: C++ nested classes, namespaces, structs, and compound statements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00082.txt.bz2 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