Re: typedef-named class member functions can be public

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  5, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

> Next time, I'll send Red Hat my bill. :-) :-)

:-P :-D

>> typedef struct { /* ... */ } *foo, **baz, bar;
>> 
>> How would you know about the class name when finishing up the class
>> type?  Or does it get done only at the end of the complete decl?

> You'd have to have a real parser, wouldn't you? :-)

Well, the current parser could presumably do it, if it was
sufficiently modified so as to delay the processing of class members
until past the point where it has the class name.  Otherwise, we have
to go back and adjust not only direct members of the class, but also
members of any nested classes, and so on and so forth.

>> I believe you, but I don't see what can go wrong.  Care to give me an
>> example, or at least a pointer?  Thanks,

> Well, if you end up generating code for any of the members at the
> closing curly brace for the class.  (They're inline, but suppose you have
> -fkeep-inline-functions.)

Aha!  I got forgotten about this flag.  Yes, it is a problem, and it
does indeed generate the wrong name for the inline function right now,
but this is not a problem because the inline function must be defined
in all translation units anyway.  Whereas for non-inline functions, it
appears to me that my patch would at least be an improvement over what
we have now, even if it might still cause problems in corner cases.

> It may be that you just can't get there from here with the current
> parser.

I concur.  It seems that it would require major surgery to get this
right :-(

> In which case, open a PR, and we'll try to fix it after we get that
> done.

Thanks.  Do you agree that my patch (or something resembling it) is an
improvement and could go in, along with a testcase?

The one thing I'm having trouble with right now is that I don't see
how to write testcases for cases in which a name should have no
linkage, but it ends up having it.  For example, there's just no way
to define a static data member or a non-inline member function of a
local, anonymous or member thereof class, so it seems to me that it is
always safe to grant such entities public linkage, no?  This is what
we do for static data members, so it seems to me that we might as well
do it for member functions.  Am I missing anything?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer