On Wed, 23 Oct 2002 19:04:04 -0400, Andrew Cagney <ac131313@redhat.com> said:
I recently noticed that the BLOCK_ macros weren't used everywhere
they could be. I know Andrew doesn't like macros, but given that
these ones are used almost everywhere, they might as well be used
everywhere.
Yep.
It's more that I like opaque types - it is all about `control' -
with an opaque type it simply isn't possible to sneak in [old] code
that grubs around in the internals. You could consider block.[hc]?
Opaque types are good, no question about that. Some of the macros in
symtab.h are also places where polymorphism would be helpful (c.f. the
recent INIT_DEMANGLED_NAME stuff), but I don't think people would be
too open to starting to rewrite parts of GDB in C++ just yet...
It's also possible using C (just a bit garish).Actually, the reason why I discovered some of these places was because
I did create block.h on carlton_dictionary-branch: I got sick of
having to recompile most of GDB every time I tried to fiddle with
struct block, so I split out struct block and struct blockvector.
(But I haven't created block.c, largely because there's only two
function prototypes that seem to clearly belong in block.h.) I posted
an RFC for splitting up symtab.h a few weeks ago, which got a tepid
response; if I decide that I like having a separate block.h, I'll
probably test the waters again in a month or so and see if I can get
approval for it on the mainline as well. (And maybe eventually split
out other parts of symtab.h later; who knows.)
Perhaphs a different marketing approach is needed. Instead of trying to
sell the ``splitting of symtab.h into 50 million little files'' (which
will have everyone running in fear :-), propose the creation of a single
large block.[hc] that contains an opaque block/vector object (which will
have everyone thinking - hmm, sounds good, can't hurt anyone, certainly
do-able, even incremental so no need to branch, ... :-).