Inline function compilation

Question

I intend to provide simple wrappers to the operating system API, which throw exceptions when errors happen. These wrappers are simple, and are all defined as inline functions in a header file. Since system API is supposed to be large, the header file is supposed to be huge as well, containing a large number of tiny inline functions. The problem is, if a shared library (.so) is compiled with the header file included, will all these tiny wrappers be compiled into the resulting binary, resulting in a large binary file, even when only a small part of the wrappers are actually used? What about the case with executables, will it be different? If it is the case, will splitting the wrappers into multiple header files be the only solution? Or should I make the wrappers internal linkage by specifying static?

Here is what I think. The wrappers may be ODR-used (e.g., taking its address). And on Linux platforms, functions with external linkage are exported by default (i.e., linkable by other binary modules). So I guess it may be necessary for the linker to actually generate outline definitions for them. Please refer to bullet point 3) in the Description section here.

A simple example wrapping CloseHandle() in Windows API:

inline void close_handle(HANDLE handle) {
  if (!CloseHandle(handle)) {
    throw std::system_error(GetLastError(), std::system_category(), "CloseHandle");
  }
}

Answer 1

A (rather small) function declared static inline (or often, just inline, or even a member function defined inside some class or struct) won't (in practice) appear in the code if it not used (see this), and will probably be inlined everywhere. Of course, you need to enable the optimizations in your compilation command. So, if using GCC, compile with g++ -Wall -O2 (and you might add -fverbose-asm -S and look inside the generated assembler code to check).

^{Some compilers (and probably g++) won't bother inlining if not asked to optimize. And inlining is always a optimization, which the compiler might not do in some occasions (in particular when storing the address of that function somewhere)}

BTW, it may look you are reinventing a framework similar to POCO or to Qt. Did you consider using them instead?

Also, recent C++11 (and C++14) implementations are already wrapping a significant part of the OS API (in particular, standard C++ IO library and C++ thread support library and more recently C++14 TS), often already using exceptions, so better leverage on them and use a recent C++ compiler (for GCC, that means GCC 5.2 in November 2015).

^{(In other words, code your thing for C++11 at least, not C++98)}

On Linux with GCC (or Clang/LLVM), if making a library, you might be interested in link-time-optimization (compile & link the library with g++ -O2 -flto), precompiled headers, visibility function attributes.

Regarding program libraries on Linux, read Program Library HowTo. For shared libraries, read Drepper's paper: How to Write Shared Libraries and this answer.

In practice, an inlined function in some library would often not be outlined in the library, but in the application program calling it. So if your shared library Foo defines in a public header <foo.h>

 inline int maxsq(int a, int b) {
    // you could add some conditional throw here...
    if (std::abs(a) < std::abs(b)) return b*b;
    else return a*a;
 }

then the object code of maxsq probably won't appear inside libfoo.so, but only in your program (which #include <foo.h> in its source code) if that program needs maxsq to be outlined, e.g. stores the address of maxsq somewhere (or if you did not ask for enough optimizations).

Remember that inlining is always an optimization, and some compiler may avoid it (even for good performance reasons) sometimes. In practice, trust your compiler (actually, your C++ implementation also includes the linker, which might "garbage collect" sections).