This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ patch] [PR 9283] Implement per-class visibility attribute [resend]


I did the overrides that way because handle_visibility_attribute (c-common.c) sets no_add_attrs=true, so the attribute is not present on the decl after the visibility bits are set in the tree_decl. I wasn't sure what the implications would be of changing that.

As for caching the class visibility on current_class_stack, I wasn't sure how to attach the attribute to the decl without passing it through to decl_attributes(), which would then wind up in handle_visibility_attribute(), which would have to somehow know that visibility is ok on a type decl, for C++ (but probably not C, since it doesn't have any meaning). This approach does have the advantage of not taking extra per-class-decl memory when visibility is specified, once the class is done being parsed.

Anyway, I'm a newbie here, so if you have any suggestions for a better way to do this I'd be happy to try it. Thanks.

Jason Merrill wrote:
Sorry I've taken so long to review this.

Why did you decide to store so much information in current_class_stack?  It
would seem simpler to me just to look up the relevant attributes when
needed.  I suppose that caching the class visibility in current_class_stack
might speed things up slightly, but the visibility_overrides scheme seems
slower than just looking for a visibility attribute on the decl.

Jason




--
-Brian Ryner
bryner@brianryner.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]