H1 2015 Priorities and Bare-Metal Programming

[captaindet via Digitalmars-d]

On 2015-02-03 05:05, Daniel Murphy wrote:
> "Walter Bright" wrote in message news:maq8ao$2idu$1 at digitalmars.com...
>
>> 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