Anonymous namespace vs static

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • gauravbjain@gmail.com

    Anonymous namespace vs static

    I am planning to move from ‘static’ keyword to anonymous namespace for
    variables/functions which are local to a translation unit. This is to
    move code closer to C++, since static for file level names is
    deprecated by standard.
    I am queries if doing this may have any downside associated with it,
    since it would give external linkage to all these names? May be size
    increase of generated object files which I believe should be taken
    care by final symbol stripping. Suggestions?

    --

  • Victor Bazarov

    #2
    Re: Anonymous namespace vs static

    gauravbjain@gma il.com wrote:
    I am planning to move from ‘static’ keyword to anonymous namespace for
    variables/functions which are local to a translation unit. This is to
    move code closer to C++, since static for file level names is
    deprecated by standard.
    I am queries if doing this may have any downside associated with it,
    since it would give external linkage to all these names? May be size
    increase of generated object files which I believe should be taken
    care by final symbol stripping. Suggestions?
    You're correct, the only potential downside is the increased number of
    external names in every module that contains objects and functions in an
    unnamed namespace. The linker is unlikely to run out of memory while
    processing them, however, I don't think you'd notice anything. The size
    of the object module should only affect the speed at which the linker
    can output the resulting executable. As you suggest, most of the modern
    linkers are smart enough to remove parts of the executable that are not
    used (or exported, in a dynamic library). Just out of curiosity, how
    big is your project?

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask

    Comment

    • =?windows-1252?Q?Marcel_M=FCller?=

      #3
      Re: Anonymous namespace vs static

      Hi,

      gauravbjain@gma il.com schrieb:
      I am planning to move from ‘static’ keyword to anonymous namespace for
      variables/functions which are local to a translation unit. This is to
      move code closer to C++, since static for file level names is
      deprecated by standard.
      static linkage is deprecated?
      Well, the second meaning of static has always been a bit confusing for
      beginners. But the anonymous namspaces are none the better. The have
      also an excemption: the implicit using statement.
      I am queries if doing this may have any downside associated with it,
      since it would give external linkage to all these names?
      I don't think so. Since the namespace has no name, the functions cannot
      be exposed by a biunique global symbol name anyway.
      May be size
      increase of generated object files
      which I believe should be taken
      care by final symbol stripping.
      Suggestions?
      Simply do it.


      Marcel

      Comment

      • Rolf Magnus

        #4
        Re: Anonymous namespace vs static

        Marcel Müller wrote:
        gauravbjain@gma il.com schrieb:
        >I am planning to move from ‘static’ keyword to anonymous namespace for
        >variables/functions which are local to a translation unit. This is to
        >move code closer to C++, since static for file level names is
        >deprecated by standard.
        >
        static linkage is deprecated?
        Yes.
        Well, the second meaning of static has always been a bit confusing for
        beginners.
        So this one is the second? Who numbered them?
        But the anonymous namspaces are none the better. The have
        also an excemption: the implicit using statement.
        Not sure what you mean by that.
        >I am queries if doing this may have any downside associated with it,
        >since it would give external linkage to all these names?
        >
        I don't think so. Since the namespace has no name, the functions cannot
        be exposed by a biunique global symbol name anyway.
        The standard requires them to have external linkage. And the compiler I use
        does actually provide them as external symbols using some unique prefix for
        the symbol name. Why it needs to do this, I don't know.

        Comment

        • Victor Bazarov

          #5
          Re: Anonymous namespace vs static

          Rolf Magnus wrote:
          [..]
          The standard requires them to have external linkage. And the compiler I use
          does actually provide them as external symbols using some unique prefix for
          the symbol name. Why it needs to do this, I don't know.
          The creators of linkers probably know. If I were asked to speculate,
          I'd probably say that the linker can utilise "near" addressing for
          symbols without external linkage and is forced to use "far" addressing
          for symbols with external linkage. It might have to play into the
          instructions the compiler creates for loading those addresses and
          passing them as arguments when calling external functions...

          V
          --
          Please remove capital 'A's when replying by e-mail
          I do not respond to top-posted replies, please don't ask

          Comment

          • James Kanze

            #6
            Re: Anonymous namespace vs static

            On Oct 1, 7:05 pm, Rolf Magnus <ramag...@t-online.dewrote:

            [re definitions in anonymous namespaces...]
            The standard requires them to have external linkage. And the
            compiler I use does actually provide them as external symbols
            using some unique prefix for the symbol name. Why it needs to
            do this, I don't know.
            Possibly for its implementation of export:-). (Seriously,
            probably just because that's the simplest solution. Generate
            the unique name, and for the rest, treat it just like anything
            else. No special cases, no extra code, etc.)

            --
            James Kanze (GABI Software) email:james.kan ze@gmail.com
            Conseils en informatique orientée objet/
            Beratung in objektorientier ter Datenverarbeitu ng
            9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

            Comment

            Working...