Re: [patch] some mindless additions of BLOCK_ macros

[Andrew Cagney <ac131313@redhat.com>]

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

Anyway, ``C++ has all the disadvantages of C, but none of the advantages 
of object oriented programming'' [gordoni].  I'd really rather wait for 
Java - universities are churning out Java programmers by the zillions.

> 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, ... :-).

Andrew