I know, that modern compilers can do procedural integration not only with functions defined inline, but also with functions residing in object files. But is this also true when you compile your program against shared library (especially dll)? Roughly speaking: will function code be copied into executable from dll, if that's desirable?
views:
62answers:
1
+4
A:
No, because the compiler does not have the code that makes up those functions.
On Windows, when you link against a dynamic library, you usually include a header and link against an import library, which simply contains the code to load the dynamic library and obtain pointers to the functions that you call (technically, you don't need the import library; you can also manually call LoadLibrary() and friends).
Since the compiler never sees the code in the dynamic library itself, it certainly can't perform inline expansion on the code.
James McNellis
2010-05-10 01:40:32
So, I suppose it's not a bad idea to define trivial methods (like accessors for example) inline rather than put their trivial bodies into dll's binary? Assuming that library is not binary-compatible-aware and sources will be recompiled with each release of it. And it will not be loaded at runtime!
doc
2010-05-10 01:53:46
@doc: I generally define trivial methods inline in a header file. However, I don't exactly know how declaring something with dllexport might affect the behavior of the optimizer (i.e., it might cause the optimizer to explicitly not perform inline expansion). I'm going to have to do some research into that one.
James McNellis
2010-05-10 02:19:44
@James McNellis: I can already tell you that, at least in g++, it is inline that affects dllexport - methods defined inline are not exported into symbols table nor their binary code is (however you must declare them inline next to the in-class declaration of class which is being exported (this is where FAQ rule [9.9] does not apply http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.9)). Of course it would be better if they will, but then without procedural integration, each trivial set or get is performed via function call mechanism, which leads to glVertex() syndrome.
doc
2010-05-10 02:48:12
The downside of doing that would be that much more of your internal data structures become exposed as part of the library's ABI, removing much of the point of using setter/getter functions in the first place.
caf
2010-05-10 02:55:56