views:

1297

answers:

5

Up till a while a ago my code base was very close to #include hell. Every time I changed an even mildly important .h file practically all the files got recompiled.
The main reason for such high header dependency was that I have many small functions that need to be inline and I was under the impression that for inline to work they need to be in the same translation unit as the calling code, so they need to be in the header. For the inline function to even compile other headers need to be included in the header as well, ad infimum.

Enter link-time code generation (in Visual Studio). One of the main stated advantages of this is that now inline function can cross translation units.
But I'm still iffy. How can I really be sure that these functions really get inlined? I realize that the compiler can basically do whatever the hell it wants no matter where I define the function.

Is there a way to check what gets inlined?

+1  A: 

Once you have the executable, you can use tools to inspect it and look for the names of the inlined functions in the symbol tables. One such tool that is mighty useful is Dependency Walker.

This of course assumes you can get a build that combines both sufficient optimization settings for the compiler to bother with inlining, while retaining symbols.

For Visual Studio, I think the "Release" builds often match those, but I'm not totally sure.

unwind
Retaining symbols is not a problem with debug info and optimizations turned on, but a function may be inlined at one place, and not at the other.
Dave Van den Eynde
Dependency walker only list exported and imported functions. Assuming I have symbols, how can I get a textual listing out of it?
shoosh
Oops, my bad, I hadn't realized. Perhaps this port of the 'nm' Unix tool does the trick: <http://www.mkssoftware.com/docs/man1/nm.1.asp>.
unwind
+3  A: 

Surely you don't really care whether things get inlined - you only care if the performance is satifactory. But if you really want to find out, examine the code the compiler generates. You can do this most easily via the debugger, using an assembler view window.

anon
+2  A: 

You can never be sure that functions are inlined. It's up to the compiler to choose that. But you can make it easier for the compiler by allowing it to find the object code associated with the function.

That's where link-time code generation comes in. The compilers don't generate object code anymore, they generate a form of intermediate language and it's the linker that actually compiles the code.

To check what gets inlined, I'm afraid you're left to generating assembly output along with your object code. That allows you to read the exact object code produced when invoken a certain function and it'll be very clear whether there's a "call" in there ore not.

Dave Van den Eynde
+2  A: 

One relatively easy way is to use a profiler. If a function is inlined you won't see it in the flow of control graph.

sharptooth
+3  A: 

I know it's taboo in C++ to say this, but you could implement the functions as preprocessor macros. Excuse me while I now go wash my mouth out with soap.

veefu
+1: Because it's sometimes the last chance to tell the compiler to "inline" your function if it absolutely insists on not inlining it, even if you absolutely know the performance would be better :-)
rstevens