Re: C++ nested classes, namespaces, structs, and compound statements

Daniel Berlin
2002-04-06T07:49:41Z

> > - 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