Re: [drow-cplus-branch rfa] using directives support

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Oct 22, 2002 at 01:18:34PM -0700, David Carlton wrote:
> 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.

I think we can get it to happen.  Eventually, at least.  We're not
quite close enough yet...

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

Well, there's strstr().  I don't know if it's portable, offhand,
though.  Better than regex would be a loop of strchr searches for '('
and strcmps, though, I think.

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

Isn't that gross?  I'm going to save this message and someday I'll put
it in the testsuite...

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

Excuse me; I was thinking of '.*'.  Which of course can not be
overridden.

> >> +/* 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.

Whew!

> >> +/* 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.

It's fine the way it is, I think.

> >> +/* 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.

But mightn't the user need to refer to more than one of the anonymous
namespaces?

> >> +  /* 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.

Sure.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer