function in unnamed namespace are inline


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 8 of 8

Thread: function in unnamed namespace are inline

  1. #1
    Join Date
    Apr 2010
    Posts
    2

    function in unnamed namespace are inline

    Please tell functions in unnamed namespace are inline.

    Case1:
    /unnamed namespace
    namespace
    {

    void initNaN(float * fvar)
    {
    const long NaN = 0x7f800001;
    long * lptr = const_cast<long*>(&NaN);
    long * lptr2;
    lptr2 = reinterpret_cast<long*>(fvar);
    *lptr2 = *lptr;
    }
    }
    //Named namspace
    namespace Named
    {
    void initNaN(float * fvar)
    {
    const long NaN = 0x7f800001;
    long * lptr = const_cast<long*>(&NaN);
    long * lptr2;
    lptr2 = reinterpret_cast<long*>(fvar);
    *lptr2 = *lptr;
    }
    }

    int main()
    {
    float fptr =123.5;
    initNaN(&fptr);
    Named::initNaN(&fptr);
    }

    When i generate the assembly code for this program.
    Case 1:
    initNan is inlined for unnamed namespace

    Case 1:
    initNan is not inlined for named namespace.

  2. #2
    Join Date
    Nov 2003
    Posts
    4,118
    There's nothing in the C++ standard that says that a function in an unnamed namespace has to be inlined. It appears that your compiler uses this technique to ensure that the member of an unnamed namespace isn't visible from other translation units (nice trick, btw) but I suspect that there's a limit to how far you can push it. Add a loop or a static variable to the function and the compiler will have to uninline it.
    Don't rely on this "property". It's not portable.
    Danny Kalev

  3. #3
    Join Date
    Apr 2010
    Posts
    2

    Funtions in unnamed namespace are inline

    namespace
    {
    class Experiment
    {
    public:
    //default inline
    int register_volatile_tests123( int sum_to )
    {
    volatile int sum(0);
    volatile register int i;
    for( i = 1; i < sum_to; i++ )
    {
    sum += i;
    }
    return sum;
    }
    //not inline
    void initNaN(float * fvar);
    //not inline
    int display_shape_type1(int choice);
    };
    }

    //Should not to be inlined
    void Experiment::initNaN(float * fvar)
    {
    const long NaN = 0x7f800001;
    long * lptr = const_cast<long*>(&NaN);
    long * lptr2;
    lptr2 = reinterpret_cast<long*>(fvar);
    *lptr2 = *lptr;
    }
    //Should not be inlined
    int Experiment::display_shape_type1(int choice)
    {
    volatile int shape_type;
    switch(choice)
    {
    case 1:
    shape_type = 1;
    break;
    default:
    shape_type = 0;
    }
    return shape_type;
    }
    Thanks Danny for ur valuable suggestion

    i have taken this example and generated assembly code for this.

    all these three functions are inlined.

  4. #4
    Join Date
    Nov 2003
    Posts
    4,118
    Looks like your compiler pushes this technique too far. It's a performance miss, especially when such long and complex functions are involved. That's one more reason to avoid unnamed namespaces and stick to good old static functions.
    btw, volatile and register are mutually exclusive.
    Danny Kalev

  5. #5
    Join Date
    Dec 2007
    Posts
    401
    I would expect a compiler which automatically inlines functions with internal linkage to inline all such functions - whether they are in unnamed namespaces or specified with static linkage specifier.

    Just turn off the compiler's automatic inlining of functions with an appropriate compiler switch. Turning this off is almost always a good idea.

  6. #6
    Join Date
    Nov 2003
    Posts
    4,118
    The thing is that functions declared in an unnamed namespace don't necessarily have internal linkage. Some implementation use external linkage in this case, giving such functions really weird mangled names. The standard doesn't guarantee/require internal linkage in this case, so there's really no reason to use this trick, especially when it can inflate executables dramatically.
    Danny Kalev

  7. #7
    Join Date
    Dec 2007
    Posts
    401
    The thing is that functions declared in an unnamed namespace don't necessarily have internal linkage. Some implementation use external linkage in this case, giving such functions really weird mangled names. The standard doesn't guarantee/require internal linkage in this case
    True enough.

    so there's really no reason to use this trick, especially when it can inflate executables dramatically.
    It is not a trick; the IS specifically recommends it over the deprecated use of the static keyword for this purpose.
    The use of the static keyword is deprecated when declaring objects in a namespace scope (see annex depr); the unnamed-namespace provides a superior alternative.
    In any case, the problem only occurs if one turns on automatic inlining of functions not specified as inline. IMHO, something that should not be enabled by default.

  8. #8
    Join Date
    Nov 2003
    Posts
    4,118
    Quote Originally Posted by vijayan View Post
    True enough.

    It is not a trick; the IS specifically recommends it over the deprecated use of the static keyword for this purpose.
    In any case, the problem only occurs if one turns on automatic inlining of functions not specified as inline. IMHO, something that should not be enabled by default.
    By "trick" I was referring to the compiler's inlining, not the use of unnamed namespaces.

    As for the deprecation of static: committee members have recently started to realize that it was a mistake (not their first one, I regret to say), and that unnamed namespaces aren't exactly a proper alternative, mostly because the linkage type of the members is unspecified. I don't know whether they had a chance to undeprecate static before the approval of the FCD (perhaps they were too busy with the noexcept hack) but static is a fine solution and there's no reason why programmers should prefer unnamed namespaces to it, especially when the compiler does foolish things such as inlining every function defined in an unnamed namespace. This is a classic example of over-engineering that led to a rash deprecation of a reasonable feature, and the introduction of a questionable feature as a "superior alternative".
    Ajay: did you try to take the address of the inlined function? Perhaps that will force the compiler to give up inlining.
    Last edited by Danny; 04-18-2010 at 03:04 PM.
    Danny Kalev

Similar Threads

  1. Replies: 8
    Last Post: 03-08-2003, 06:25 PM
  2. Replies: 0
    Last Post: 06-19-2001, 02:04 PM
  3. verify local admin
    By Patrick Comeau in forum VB Classic
    Replies: 6
    Last Post: 03-22-2001, 10:50 PM
  4. How do I detect an FTP timeout?
    By Julian Milano in forum VB Classic
    Replies: 2
    Last Post: 08-11-2000, 12:11 PM
  5. Trying to print a PDF File from VB
    By Kunal Sharma in forum VB Classic
    Replies: 2
    Last Post: 04-25-2000, 03:45 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center