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

David Carlton
2002-10-22T20:18:36Z

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.