On Wed, May 15, 2013 at 9:47 PM, Rafael Espíndola < [email protected]> wrote:
> > Well, improper use of italics aside, my view is that that rule does *not* > > define when an entity has external linkage. Instead, that text is > describing > > a consequence of the declaration having external linkage (and by "can be > > referred to" it really means "you don't need to block identical entities > in > > different translation units from linking together"). > > > > I do agree that the standard may not say what we want here, and isn't > > completely clear; I filed core issue 1602 for that a few months ago for > > exactly that. However, it's not been decided by CWG yet, and since > (AFAICT) > > it would only affect which diagnostics are mandatory and it would make > > 'linkage' much more expensive to compute, there's a good chance that > they'll > > say it's NAD. > > I am not sure I follow the "more expensive" argument. Any compiler (as > opposed to a theoretical tool that just checks if a string is valid > c++) will have to compute something like the linkage we compute, no? I think would be sufficient to use a globally-unique mangling for names inside anonymous namespaces and non-inline functions (like gcc used to), or to generate an 'externally visible' flag as a side-effect of computing the mangled name. But you don't need to do any of that if you're not generating code, and there are many C++-parsing tools out there which do not generate code. > > You should also be aware of core issue 1603, which brings the linkage > rules > > more into line with how we behave. > > Cheers, > Rafael >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
