24-Feb-2014 03:49, Walter Bright пишет:
On 2/23/2014 3:00 PM, Dmitry Olshansky wrote:
You actually going against yourself with this argument - for porting you
typically suggest:
version(OS1)
...
else version(OS2)
...
else
static assert(0);
There's not much choice about that. I also suggest moving such code into
separate modules.
Your nice tired and true way of doing things is EQUALLY FRAGILE (if
not more)
and highly coupled to the compiler but only SILENTLY so.
That's very true. Do you suggest the compiler emit a list of what
optimizations it did or did not do? What makes inlining special, as
opposed to, say, enregistering particular variables?
GCC has these attributes (including flatten to fully unroll all calls in
a function) for a good reason. Let's face the fact that compilers
nowhere near perfect with decisions about inlining. Especially so when
building libraries.
Inlining is special in the sense that compiler doesn't know (there is
not a single hint today in D) if any particular function should be a
part of object code (following the ABI and referenced elsewhere) or just
a logical piece of code that is reused (using any convenient calling
convention or inlined).
Let me turn the question sideways - what if no_inline will be a hint to
compiler and it may feel free to inline the function anyway? Will you be
happy with such a pragma? It's that simple - you either gain control, or
stay with wishy-washy hopes.
As you said in contrast with register allocation (that is ridiculously
hard problem) later with time it turned out that trying to pin outsmart
the compiler is something people were not good at in general.
--
Dmitry Olshansky
