On 2015-02-03 05:05, Daniel Murphy wrote:
"Walter Bright" wrote in message news:[email protected]...
Yup. I understand the concern that a compiler would opt out of
inlining those if it legally could, but I just cannot see that
happening in reality. Modern compilers have been inlining for 25
years now, and they're not likely to just stop doing it.
No, the problem is that the code might accidentally contain a
construct that is not inlineable. The user will expect it to be
inlined, but the compiler will silently fail.
eg
void myWrapperFunc()
{
callSomeFunc(999, 123, "something");
}
This function will not be inlined if callSomeFunc has a default
arugment that calls alloca, for example. If a hidden failure becomes
a compiler error, the user can trivially correct the problem.
+1
i am a simple user writing mostly programs to crunch my scientific data. i'd
like to move my C code to D. but i deal with GBs of data that i have to sieve
through many times. in C, i have lots of repeating integer stunts in the inner
loop that must be inlined. i used macros for this. if i cannot mark small
helper function in the inner loop so that they are guaranteed to be inlined, i
am screwed. i would have to copy and paste lots of code, making the result
worse than the C code.
i am fine with a compilation error when force_inclining fails, if it comes with a
brief explanation of why so i get an idea of how to fix it and make it work. i am
not writing or reading assembler and i don't plan to. but i also don't want to be
in doubt about the inlining. i just want to get stuff done in a convenient way. if
D offers no way other than copy&pasting code blocks i cannot use it for my
work. sadly.
/det
