From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13944 invoked by alias); 24 Oct 2002 00:20:17 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13934 invoked from network); 24 Oct 2002 00:20:17 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 24 Oct 2002 00:20:17 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g9O0KAr29807; Wed, 23 Oct 2002 17:20:10 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] some mindless additions of BLOCK_ macros References: <3DB72AE4.1040908@redhat.com> <3DB737CA.3080308@redhat.com> From: David Carlton Date: Wed, 23 Oct 2002 17:20:00 -0000 In-Reply-To: <3DB737CA.3080308@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00501.txt.bz2 On Wed, 23 Oct 2002 19:59:06 -0400, Andrew Cagney said: > 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. I confess, I'm getting more respect for C++ the more I learn about it. I don't know Java too well yet, though, and certainly having garbage collection would be nice. (But not worth rewriting all of GDB to get.) > 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, ... :-). That's kind of what I'm doing. Right now, the first plan is to just try to create a separate block.h, taken straight out of symtab.h: surely nobody could mind such an innocent action as that? The resulting struct block won't be any more opaque than it currently is, though. But the main place where it could use some opacity is in its hashtable, nsyms, and sym members: and there I have a working version of GDB that handles those using an opaque struct dictionary. But I need a good excuse to spring that struct dictionary part on people; right now, it honestly isn't adding anything other than code cleanliness. Having it around would have made the transition from sorted linear blocks to hashtable blocks a lot easier; but that transition has already happened. And it's possible that I'll find a good use for it in the namespace stuff that will require me to rejigger it slightly; so it's perhaps best to wait until after I've got a bit more of that under my belt. David Carlton carlton@math.stanford.edu