inlining or not inlining...

[Stewart Gordon]

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.