From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4278 invoked by alias); 22 Oct 2002 20:18:36 -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 4270 invoked from network); 22 Oct 2002 20:18:35 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 22 Oct 2002 20:18:35 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g9MKIY623504; Tue, 22 Oct 2002 13:18:34 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [drow-cplus-branch rfa] using directives support References: <20021022024516.GA24007@nevyn.them.org> From: David Carlton Date: Tue, 22 Oct 2002 13:18:00 -0000 In-Reply-To: <20021022024516.GA24007@nevyn.them.org> 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/msg00415.txt.bz2 On Mon, 21 Oct 2002 22:45:16 -0400, Daniel Jacobowitz said: > On Mon, Oct 21, 2002 at 05:10:08PM -0700, David Carlton wrote: > It's approved, with some comments for you to think about. Thanks; committed. > You're doing a truly heroic amount of work here... Thanks. Actually, it's not so bad; if you look at the ChangeLog for carlton_dictionary-branch, you'll see that it's all been pleasantly incremental so far. Having said that, if we ever get to the situation where, given this code: namespace A { int x = 1; } namespace B { namespace A { int y = 2; } void foo() { return; } } and where we're at a breakpoint inside of B::foo(), if we can get a lookup of A::x to fail (and one of ::A::x to succeed), then that will be pretty impressive. I'm not exactly looking forward to reworking symbol lookup stuff to use iterators, either, or to getting Koenig lookup to work. >> +static void >> +scan_for_anonymous_namespaces (struct symbol *symbol) >> +{ >> + const char *name = SYMBOL_CPLUS_DEMANGLED_NAME (symbol); >> + const char *beginning, *end; >> + >> + /* FIXME: carlton/2002-10-14: Should we do some sort of fast search >> + first to see if the substring "(anonymous namespace)" occurs in >> + name at all? */ > Definitely! This is a hideously expensive search here... Yah. What's the right way to do this? regex? There doesn't seem to be anything appropriate in the C standard library. >> + - And operator names can contain parentheses or angle brackets. >> + Fortunately, I _think_ that operator names can only occur in a >> + fairly restrictive set of locations (in particular, they have be >> + at depth 0, don't they?). */ > No :( This is one of the more hideous pieces of C++ I've ever written > and it took a little time to come up with: > class B { > public: > }; > int operator+ (B const &, B const &) > { > return 1; > } > template class C { > public: > static void * const cmem = T; > int member(void); > }; > int theInt; > template int C::member(void) { > return 0; > } > C<(void *) &theInt> theC; > C<(void *) &operator+> theOtherC; > int func() > { > return theOtherC.member(); > } > Gives us this gem: > 00000000 W C<&operator+(B const &, B const &)>::member(void) Gosh. Charming. Or something. I think I'll wait until somebody submits a bug report complaining about that one. > Not sure if this presents a problem; the parentheses in an operator > name will be matched, and you can't define an operator->, can you? Of course you can: this is C++, a language that allows you to redefine &&, ||, and the comma operator. In fact, you define it all the time when doing smart pointers. (And I just learned yesterday that operator-> has its own peculiar semantics; see chapter 7 of Alexandrescu's _Modern C++ Design_. But that's really not something I'm worried about at all right now.) >> +/* FIXME: carlton/2002-10-09: Do all the functions here handle all the >> + above considerations correctly? */ > Almost certainly not; I hadn't thought about the (anonymous namespace) > thing. It may be misdetected as the arg list; if it isn't, it's blind > luck. I skimmed it, and actually I think you were lucky: basically, you're okay since (anonymous namespace) can never occur after the arg list, just before it (or in the middle of it), and you search from the back instead of the front. >> +/* Let's optimize away calls to strlen("operator"). */ >> + >> +#define LENGTH_OF_OPERATOR 8 > A recent GCC will do this for you, actually. If glibc doesn't get in > its way, at least. Hmm. I don't think I want to put those strlen()s any place where they could be called more than once, but I could consider doing static const int length_of_operator = strlen("operator"); instead. That wouldn't have much of a performance penalty on other compilers. >> +/* FIXME: carlton/2002-10-07: That anonymous namespace example isn't >> + that great, since it really depends not only on what the >> + demangler's output is but also on the fact that the demangler's >> + output doesn't depend on the name of the file in question. Which, >> + alas, it doesn't, but should, leaving us with no way to distinguish >> + between anonymous namespaces in different files. Sigh... */ > They may be responsive to fixing that... Yeah, I'll think about that. It's an easy enough hack to handle this correctly within GDB, but it's still a hack. There is one benefit to the current framework: if a user wants to explicitly refer to anonymous namespaces, then it would be easier for the user to just have to write '(anonymous namespace)::foo' instead of some more complicated demangled thing. But I don't know how likely that is. >> + /* FIXME: carlton/2002-10-10: is "is_a_field_of_this" always >> + non-NULL if we're in the C++ case? Maybe we should always do >> + this, and delete the two previous searches: this will always >> + search the global namespace, after all. */ > I don't think it'll always be non-NULL - I think it's just set when the > caller cares about the answer. And why are searches in using > directives conditioned on this argument? Okay, then I'll change that accordingly; when we get around to merging it into mainline, we can revisit the issue. David Carlton carlton@math.stanford.edu