Тогда у D нет никаких преимуществ перед C++ нет даже в этом случае, если компилятор может заинлайнить, а может и нет (потому что не умеет, потому что эвристика решила что не стоит или по любой другой причине).
Я и не спорю, но в данном случае, приведённом в статье, всё инлайнится. А случае из вашего комментария — нет. А код в стандартной библиотеке один и тот же. Так что, тут у C++ преимущество: инлайнится когда возможно, и дублирование кода для покрытия обоих случаев не требуется.
IPSec в IPv6 обязательное в том смысле, что узел обязательно должен поддерживать IPSec чтобы говорить о поддержке IPv6. Это не значит, что в IPv6 весь трафик шифруется.
Не соответствует стандарту. std::transform не обязан в функтор кормить элементы по порядку.
Effects: Assigns through every iterator i in the range [result,result + (last1 — first1)) a new corresponding value equal to op(*(first1 + (i — result)) or binary_op(*(first1 + (i — result)), *(first2 + (i — result))).
<source=c>if(fmod(window,2)==0)
fmod для целых чисел да ещё и сравнение на строгое равенство чисел с плавающей запятой…
> C++ edition
и где тут C++? Это си, не более.
На каждый элемент результирующего массива лишние ветвления: особые случаи для начала и конца нужны только в начале и в конце, а основной объём данных должен обрабатываться без этого.
Трюк с вычитанием хорош только если вы уверены что не произойдёт никаких катастрофических округлений.
Не правда, всё отлично инлайнится.
IPSec в IPv6 обязательное в том смысле, что узел обязательно должен поддерживать IPSec чтобы говорить о поддержке IPv6. Это не значит, что в IPv6 весь трафик шифруется.
fmod для целых чисел да ещё и сравнение на строгое равенство чисел с плавающей запятой…
> C++ edition
и где тут C++? Это си, не более.
На каждый элемент результирующего массива лишние ветвления: особые случаи для начала и конца нужны только в начале и в конце, а основной объём данных должен обрабатываться без этого.
Трюк с вычитанием хорош только если вы уверены что не произойдёт никаких катастрофических округлений.