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: Gianni Mariani <gianni at mariani dot ws>
- 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 09:26:18 -0800
- Subject: Re: C++ nested classes, namespaces, structs, and compound statements
- References: <Pine.LNX.4.44.0204060236110.25262-100000@dberlin.org>
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
>