From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11485 invoked by alias); 6 Apr 2002 17:26:28 -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 11476 invoked from network); 6 Apr 2002 17:26:27 -0000 Received: from unknown (HELO xcncgw.mariani.ws) (208.176.14.66) by sources.redhat.com with SMTP; 6 Apr 2002 17:26:27 -0000 Received: from mariani.ws (IDENT:gianni@bulli.mariani.ws [216.98.238.112]) by xcncgw.mariani.ws (8.11.6/8.11.6) with ESMTP id g36IQ5s17706; Sat, 6 Apr 2002 10:26:05 -0800 Message-ID: <3CAF2FBA.5040000@mariani.ws> Date: Sat, 06 Apr 2002 09:26:00 -0000 From: Gianni Mariani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313 X-Accept-Language: en-us, 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; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00085.txt.bz2 As a complete digression: Although this problem might need to be solved in the fashion presented here, I can't help but think we're trying to solve the wrong problem. Much of what is discussed here is language and compiler specific. My generic approach to solving this kind of problem is to provide an abstraction layer where all the facilities are provided for in a API (abstract base interface class); the mapping is then language and compiler specific. The burden is then on the compiler writer to provide the symbol binding mechanism/implementation which is where it belongs. This then buys all kinds of nice things like unit testability. If the compiler writer makes a change, the compiler tests fail way before it even gets to running gdb. In other words, "Place the responsibility with the knowledge". The question is - how do you provide an abstraction that makes sense for all languages ? (or at least *most* languages). BTW- "Amazingly tedious refactoring" is somthing that a editor macro can help with. I constantly have people in my development team who want to make global changes and I end up doing them because I've taken the time to learn how to use my editor's keyboard macros. The reason you *should* use them is that you can guarentee a consistant change. So how about this silly challenge: a) Someone define a new interface for symbol look up. b) Someone implement the interface so it is in an independant module. c) I'll mod the code to use the new interface I'll bet a keg of beer I can do c) it in less time it takes someone to do a) and b). .... I feel I'm going to regret this .... :) Daniel Berlin wrote: >>>- How would we introduce this incrementally? >>> >>Do we want to? >> >>No, I'm serious. Incremental solutions are more practical to >>implement, but they will come with more baggage. Baggage will haunt us >>for a very long time. If we can completely handle non-minimal-symbol >>lookup in this way, that's a big win. >> > >You might be able to pull something off like i did on the >new-typesystem-branch (which is unfinished, but quite far along. It was >left ina non-compiling stabs because i was in the midst of stabs fixes >when i stopped working on it). > >I modified a single type class at a time, replacing it with a compatible >structure with the added members, then changed the functions gradually to >fill in the extra members, then use the extra members, then not use the >old members, then removed the old members. Somewhere in there ,I >created new type creation functions (one for each type class), and changed >the symbol readers to use them when approriate. > >Adding a struct environment is probably comparable in the amount of >work/places to touch. > >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). > >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. > >--Dan >