Static linkage and anonymous namespace

Mark Mitchell mark@markmitchell.com
Mon Aug 31 14:59:00 GMT 1998


>>>>> "Martin" == Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de> 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.

Like all warnings (as opposed to errors), there will ocasionally be
cases where these warnings will not be helpful, and there will be
people who will want them and people who do not.  One thing GCC should
get, in the future, is a warning/error catalog, with ways
(command-line switch, #pragma, __attribute__, etc.) of turning them on
and off.  For example, the EDG front-end allows you to make warnings
into errors, or turn them off completely.  A nice feature.

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.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com



More information about the Gcc-patches mailing list