Scope of inline functions

[Ondrej Spanel]

I though that inline functions should be always visible only in the
compilation unit where they are defined - meaning if compiler cannot inline
them, they should be handled as if declared static. However sample attached
shows VC compiler does not work this way (tested in .NET 2003). When you
compile the sample with inlining enabled (like in default Release config),
the output is A1 = 1, A2 = 2. When run with inlining disabled (Debug),
output is A1 = 1, A2 = 1 - the compiler/linker uses the same version of the
A function in both compilation units, and it even gives no warning.

When I use "static inline" instead of "inline" for both A functions, it
works as expected. When I do not use any qualification (or use extern), the
linker gives error A is defined twice. My conclusion is current behaviour
with"inline" is both inconsistend and unsafe, as any compilation unit may
unknowningly use different inline function in case inline function is not
inlined (which is somethnig compiler is free to decide, and it is normal in
debug builds).

I recently experienced very similiar issue with global operator new - even
if it was inlined, it was shared accross various modules, leading to
unexpected behaviour. The issue was quite confusing, as I did not expect at
all other modules (in this case static libraries) could see my (inlined)
definition of operator new.

Regards
Ondrej

---------------------------------------
Ondrej Spanel
Lead Programmer
Bohemia Interactive Studio
www.bistudio.com
www.flashpoint1985.com
////////////////////////////////////////////////////////////////////////////
////////////
/// first.cpp
#include <stdio.h>
inline int A()
{
return 1;
}
int CallA2();

int CallA1()
{
return A();
}
int main(int argc, const char *argv[])
{
printf("A1 = %d\n",CallA1());
printf("A2 = %d\n",CallA2());
getchar();
return 0;
}
/// end of first.cpp

////////////////////////////////////////////////////////////////////////////
////////////
/// second.cpp
inline int A()
{
return 2;
}
int CallA2()
{
return A();
}
/// end of second.cpp

[Ondrej Spanel]

Can anyone please confirm if this is bug (seems like that to me), or is
there some problem in the code provided?

Regards
Ondrej

"Ondrej Spanel" <on***********@bistudionospam.com> wrote in message
news:eT*************@TK2MSFTNGP11.phx.gbl...

I though that inline functions should be always visible only in the
compilation unit where they are defined - meaning if compiler cannot inline them, they should be handled as if declared static. However sample attached shows VC compiler does not work this way (tested in .NET 2003). When you
compile the sample with inlining enabled (like in default Release config),
the output is A1 = 1, A2 = 2. When run with inlining disabled (Debug),
output is A1 = 1, A2 = 1 - the compiler/linker uses the same version of the A function in both compilation units, and it even gives no warning.

When I use "static inline" instead of "inline" for both A functions, it
works as expected. When I do not use any qualification (or use extern), the linker gives error A is defined twice. My conclusion is current behaviour
with"inline" is both inconsistend and unsafe, as any compilation unit may
unknowningly use different inline function in case inline function is not
inlined (which is somethnig compiler is free to decide, and it is normal in debug builds).

I recently experienced very similiar issue with global operator new - even
if it was inlined, it was shared accross various modules, leading to
unexpected behaviour. The issue was quite confusing, as I did not expect at all other modules (in this case static libraries) could see my (inlined)
definition of operator new.

Regards
Ondrej

---------------------------------------
Ondrej Spanel
Lead Programmer
Bohemia Interactive Studio
www.bistudio.com
www.flashpoint1985.com
//////////////////////////////////////////////////////////////////////////// ////////////
/// first.cpp
#include <stdio.h>
inline int A()
{
return 1;
}
int CallA2();

int CallA1()
{
return A();
}
int main(int argc, const char *argv[])
{
printf("A1 = %d\n",CallA1());
printf("A2 = %d\n",CallA2());
getchar();
return 0;
}
/// end of first.cpp

//////////////////////////////////////////////////////////////////////////// ////////////
/// second.cpp
inline int A()
{
return 2;
}
int CallA2()
{
return A();
}
/// end of second.cpp

[David Lowndes]

"Ondrej Spanel" <on***********@bistudionospam.com> wrote:

I though that inline functions should be always visible only in the
compilation unit where they are defined - meaning if compiler cannot inline
them, they should be handled as if declared static. However sample attached
shows VC compiler does not work this way (tested in .NET 2003). When you
compile the sample with inlining enabled (like in default Release config),
the output is A1 = 1, A2 = 2. When run with inlining disabled (Debug),
output is A1 = 1, A2 = 1 - the compiler/linker uses the same version of the
A function in both compilation units, and it even gives no warning.

When I use "static inline" instead of "inline" for both A functions, it
works as expected. When I do not use any qualification (or use extern), the
linker gives error A is defined twice. My conclusion is current behaviour
with"inline" is both inconsistend and unsafe, as any compilation unit may
unknowningly use different inline function in case inline function is not
inlined (which is somethnig compiler is free to decide, and it is normal in
debug builds).

I recently experienced very similiar issue with global operator new - even
if it was inlined, it was shared accross various modules, leading to
unexpected behaviour. The issue was quite confusing, as I did not expect at
all other modules (in this case static libraries) could see my (inlined)
definition of operator new.

Regards
Ondrej

---------------------------------------
Ondrej Spanel
Lead Programmer
Bohemia Interactive Studio
www.bistudio.com
www.flashpoint1985.com
////////////////////////////////////////////////////////////////////////////
////////////
/// first.cpp
#include <stdio.h>
inline int A()
{
return 1;
}
int CallA2();

int CallA1()
{
return A();
}
int main(int argc, const char *argv[])
{
printf("A1 = %d\n",CallA1());
printf("A2 = %d\n",CallA2());
getchar();
return 0;
}
/// end of first.cpp

////////////////////////////////////////////////////////////////////////////
////////////
/// second.cpp
inline int A()
{
return 2;
}
int CallA2()
{
return A();
}
/// end of second.cpp

--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Bo Persson]

"Ondrej Spanel" <on***********@bistudionospam.com> skrev i meddelandet
news:eL**************@TK2MSFTNGP09.phx.gbl...

Can anyone please confirm if this is bug (seems like that to me), or is there some problem in the code provided?
No, it is not a bug. The problem is with your code.

Inline does not change the visiblity of the function, it just hints
the compiler that you want it inlined, if possible. C++ has a "one
definition rule" which says you are allowed to repeat the definition
of an inlines function, provided that all definitions are the same. In
your case they are obviously not.

*If* all functions are inlined, you might get away with the error,
because it is hard to detect the it. It is still an error though.
If you want functions local to a specific cpp-file, you can put them
in an anonymous namespace. That hides them from the outside (by
generating a unique name).
Bo Persson

Regards
Ondrej

"Ondrej Spanel" <on***********@bistudionospam.com> wrote in message
news:eT*************@TK2MSFTNGP11.phx.gbl...

I though that inline functions should be always visible only in the compilation unit where they are defined - meaning if compiler cannot

inline

them, they should be handled as if declared static. However sample attached

shows VC compiler does not work this way (tested in .NET 2003).

When you compile the sample with inlining enabled (like in default Release config), the output is A1 = 1, A2 = 2. When run with inlining disabled (Debug), output is A1 = 1, A2 = 1 - the compiler/linker uses the same version of the

A function in both compilation units, and it even gives no

warning.
When I use "static inline" instead of "inline" for both A functions, it works as expected. When I do not use any qualification (or use extern), the

linker gives error A is defined twice. My conclusion is current

behaviour with"inline" is both inconsistend and unsafe, as any compilation unit may unknowningly use different inline function in case inline function is not inlined (which is somethnig compiler is free to decide, and it is normal in

debug builds).

I recently experienced very similiar issue with global operator

new - even if it was inlined, it was shared accross various modules, leading to unexpected behaviour. The issue was quite confusing, as I did not expect at

all other modules (in this case static libraries) could see my

(inlined) definition of operator new.

Regards
Ondrej

---------------------------------------
Ondrej Spanel
Lead Programmer
Bohemia Interactive Studio
www.bistudio.com
www.flashpoint1985.com

//////////////////////////////////////////////////////////////////////
//////

////////////
/// first.cpp
#include <stdio.h>
inline int A()
{
return 1;
}
int CallA2();

int CallA1()
{
return A();
}
int main(int argc, const char *argv[])
{
printf("A1 = %d\n",CallA1());
printf("A2 = %d\n",CallA2());
getchar();
return 0;
}
/// end of first.cpp

//////////////////////////////////////////////////////////////////////
//////

////////////
/// second.cpp
inline int A()
{
return 2;
}
int CallA2()
{
return A();
}
/// end of second.cpp

[Ondrej Spanel]

> No, it is not a bug. The problem is with your code.

Inline does not change the visiblity of the function, it just hints
the compiler that you want it inlined, if possible. C++ has a "one
definition rule" which says you are allowed to repeat the definition
of an inlines function, provided that all definitions are the same. In
your case they are obviously not.

Thank you for your explanation. I searched the net and came to the same
conclusion. However there is still one thing which I am convinced is a bug
in Visual C++ - and that is that the problem in my code in undetected and
"random" function implementation is selected of those I provided. I would
expect to get some linker error or warning in such situation - and I think
it should be quite easy for the linker to see the two definitions are not
the same (maybe I am mistaken in this)?

Regards
Ondrej

"Ondrej Spanel" <on***********@bistudionospam.com> wrote in message
news:eT*************@TK2MSFTNGP11.phx.gbl...

I though that inline functions should be always visible only in the compilation unit where they are defined - meaning if compiler cannot

inline

them, they should be handled as if declared static. However sample

attached

shows VC compiler does not work this way (tested in .NET 2003).

When you compile the sample with inlining enabled (like in default Release config), the output is A1 = 1, A2 = 2. When run with inlining disabled (Debug), output is A1 = 1, A2 = 1 - the compiler/linker uses the same version of

the

A function in both compilation units, and it even gives no

warning.
When I use "static inline" instead of "inline" for both A functions, it works as expected. When I do not use any qualification (or use extern),

the

linker gives error A is defined twice. My conclusion is current

behaviour with"inline" is both inconsistend and unsafe, as any compilation unit may unknowningly use different inline function in case inline function is not inlined (which is somethnig compiler is free to decide, and it is normal

in

debug builds).

I recently experienced very similiar issue with global operator

new - even if it was inlined, it was shared accross various modules, leading to unexpected behaviour. The issue was quite confusing, as I did not expect

at

all other modules (in this case static libraries) could see my

(inlined) definition of operator new.

Regards
Ondrej

---------------------------------------
Ondrej Spanel
Lead Programmer
Bohemia Interactive Studio
www.bistudio.com
www.flashpoint1985.com

//////////////////////////////////////////////////////////////////////
//////

////////////
/// first.cpp
#include <stdio.h>
inline int A()
{
return 1;
}
int CallA2();

int CallA1()
{
return A();
}
int main(int argc, const char *argv[])
{
printf("A1 = %d\n",CallA1());
printf("A2 = %d\n",CallA2());
getchar();
return 0;
}
/// end of first.cpp

//////////////////////////////////////////////////////////////////////
//////

////////////
/// second.cpp
inline int A()
{
return 2;
}
int CallA2()
{
return A();
}
/// end of second.cpp

[Bo Persson]

"Ondrej Spanel" <on***********@bistudionospam.com> skrev i meddelandet
news:%2***************@TK2MSFTNGP11.phx.gbl...

No, it is not a bug. The problem is with your code.

Inline does not change the visiblity of the function, it just hints

the compiler that you want it inlined, if possible. C++ has a "one
definition rule" which says you are allowed to repeat the definition of an inlines function, provided that all definitions are the same. In your case they are obviously not.
Thank you for your explanation. I searched the net and came to the

same conclusion. However there is still one thing which I am convinced is a bug in Visual C++ - and that is that the problem in my code in undetected and "random" function implementation is selected of those I provided. I would expect to get some linker error or warning in such situation - and I think it should be quite easy for the linker to see the two definitions are not the same (maybe I am mistaken in this)?
It is not really a bug, even though I agree that it would be nice if
the linker warned you.

The problem is that the linker isn't required to be C++ specific, only
the compiler is. On some systems the same linker is used for all
compilers, so the C++ cannot put any language specific requirements on
it.

Also, by not following the "one definition rule" technically you have
broken the contract with the compiler, and it can do just anything at
all. Issuing a warning is definitely allowed, but not required.
Bo Persson


Regards
Ondrej
"Ondrej Spanel" <on***********@bistudionospam.com> wrote in message news:eT*************@TK2MSFTNGP11.phx.gbl...
> I though that inline functions should be always visible only in

the

> compilation unit where they are defined - meaning if compiler

cannot

inline
> them, they should be handled as if declared static. However

sample attached
> shows VC compiler does not work this way (tested in .NET

2003). When you

> compile the sample with inlining enabled (like in default

Release config),

> the output is A1 = 1, A2 = 2. When run with inlining disabled

(Debug),

> output is A1 = 1, A2 = 1 - the compiler/linker uses the same

version of

the
> A function in both compilation units, and it even gives no

warning.

>
> When I use "static inline" instead of "inline" for both A

functions, it

> works as expected. When I do not use any qualification (or use

extern),

the
> linker gives error A is defined twice. My conclusion is

current behaviour

> with"inline" is both inconsistend and unsafe, as any

compilation unit may

> unknowningly use different inline function in case inline

function is not

> inlined (which is somethnig compiler is free to decide, and it

is normal

in
> debug builds).
>
> I recently experienced very similiar issue with global

operator new - even

> if it was inlined, it was shared accross various modules,

leading to

> unexpected behaviour. The issue was quite confusing, as I did

not expect

at
> all other modules (in this case static libraries) could see my

(inlined)

> definition of operator new.
>
> Regards
> Ondrej
>
> ---------------------------------------
> Ondrej Spanel
> Lead Programmer
> Bohemia Interactive Studio
> www.bistudio.com
> www.flashpoint1985.com
>
>
>

////////////////////////////////////////////////////////////////////// //////

> ////////////
> /// first.cpp
> #include <stdio.h>
> inline int A()
> {
> return 1;
> }
> int CallA2();
>
> int CallA1()
> {
> return A();
> }
> int main(int argc, const char *argv[])
> {
> printf("A1 = %d\n",CallA1());
> printf("A2 = %d\n",CallA2());
> getchar();
> return 0;
> }
> /// end of first.cpp
>
>

////////////////////////////////////////////////////////////////////// //////

> ////////////
> /// second.cpp
> inline int A()
> {
> return 2;
> }
> int CallA2()
> {
> return A();
> }
> /// end of second.cpp
>
>