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

[David Carlton <carlton at math dot stanford dot edu>]

On Mon, 21 Oct 2002 22:45:16 -0400, Daniel Jacobowitz <drow@mvista.com> 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 <void *T> class C {
> public:
>   static void * const cmem = T;
>   int member(void);
> };

> int theInt;

> template <void *T> int C<T>::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