function in unnamed namespace are inline

[ajay.yadav]

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.

[Danny]

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.

[ajay.yadav]

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.

[Danny]

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.

[vijayan]

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.

[Danny]

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.

[vijayan]

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.

[Danny]

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.