This is the mail archive of the 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]

Re: Static linkage and anonymous namespace

>>>>> Mark Mitchell <> writes:

>>>>> "Martin" == Martin von Loewis <> writes:
 >>> So, we can make it `static' in the C sense.  So, it's fair to
 >>> warn on:
 >>> namespace { struct S {}; } void f(vector<S> vs);
 >>> but it's not fair to make that an *error*; it's actually legal,
 >>> I think.

 Martin> Why would I even warn on that? If I later get an
 Martin> implementation for f, fine, if I don't - well, I can't
 Martin> supply one in another translation unit, so it remains
 Martin> unresolved.

 > In the latter case in it's certainly reasonable to warn; if there's no
 > implementation, then, as you point out, there's no way to *ever*
 > define the functions, so a warning is in order.  This is akin to a
 > "static-function-declared-but-not-defined" warning.


 > Even in the first case it's reasonable to warn; there's no point in
 > giving external linkage to such a function since it can't really be
 > called from somewhere else.

No; 'static' is deprecated, now that we have the unnamed namespace.

 > I'm not particularly interested in scrapping over whether or not the
 > warnings I proposed are useful; I'm more interested in not going to a
 > lot of trouble to give functions that involve types in anonymous
 > namespaces internal linkage.

 > In fact, I'm not even sure we should give functions in an anonymous
 > namespace internal linkage.  Maybe we can dream up cases where people
 > will use assembly language to call them from other files?  It seems
 > simplest to map C++'s internal/external linkage directly onto
 > traditional linker semantics.



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