On 11/02/2011 06:35, Walter Bright wrote:
<snip>
I hate not being able to force functions to be inline. A consequence is that
you can't
fully interface certain APIs without an extra .lib over what would be needed in
C(++).
You cannot force inlining in C(++) either. The inline keyword is only a
suggestion.
But is the inline keyword guaranteed to prevent a duplicate symbol error at link time when
multiple modules contain this same function after preprocessing?
I'm not understanding your last comment that a .lib would be required. That's
not correct,
as since you're supplying the full source anyway (needed for inlining), just
compile in
that source from the command line. No lib step is needed.
OK, so a .lib isn't strictly necessary, a .obj will do. But for an example of what I'm on
about, consider the many #define macros in the C headers of the Windows API. In D, these
become functions, and you can't tell the compiler to inline them. Therefore you have to
compile the Windows API bindings as modules in their own right, and then link them in,
whereas in C(++) you need only to compile and link your own source files (along with a few
standard Windows .libs).
Consequently, all these functions might end up in the .exe even though they are never
used, either because the application code never uses them or because the compiler has
inlined them where they are used.
Stewart.
