Оказывается я фортран в серьёзных проектах использовал. Интересно как, если я его толком не знаю? А если серьёзно, то у меня пока нет завершённых проектов на c++, имеющих какое либо иное назначение кроме научных вычислений. Для остального бейсик, паскаль и
внимание... фортран! Спектрумовскеий бейсик проблем с синонимами не имеет, но даже в мануэле к нему пишут, что бейсик-программы исполняются в
50 раз медленнее, чем компилированные и даже не уточняется, с какого языка компилированные, видимо имеется ввиду некая усреднённая скорость исполнения программ. Не мифическая проблема синонимов влияет на скорость исполнения, а совсем другие факторы. Во-первых интерпретация текста медленнее исполнения натива. Но даже в мануале к балсту, а это оптимизирующий компилятор бейсика, обещано ускорение по сравнению со встроенным интерпретатором всего в 36 раз, а не в 50. Тормоза также появляются, когда до рантайма доживает таблица переменных. Плохое решение, но возможное, если кто задастся целью сделать пессимизирующий компилятор, то может быть именно так компилируемые им программы и будут тормозить. Но хорошие компиляторы так не делают, не зависимо от языка. Следующие факторы: избыточные проверки и не только на выход за пределы массива и переувлечение вариэнтом и подобными ему типами. Дальше идёт переувлечение действительными типами. На спектрумовском бейсике нет целого типа, так что даже счётчики всех циклов приходится юзать действительные. Инкрмент быстрее, чем
, так как икремент выполняется за одну операцию, а
- это сначала копирование i в буфер, потом увеличение его на единицу операцией ADD, требующей к тому же загрузки лишнего операнда, а потому могущей выполняться медленнее, чем INC, а потом копирование суммы в I. И здесь приходим к вопросу о качестве оптимизатора в компиляторе, если он способен заменить всю цепочку на INC, то скорость исполнения от отсутствия в языке инкремента не пострадает, а если нет, то пострадает. На c++ же уже есть готовый инкремент.
тоже быстрей, чем
, так как
- это просто ADD, а
- ADD с двумя копированиями. Но это различие проявляется только если x уже хранится в регистре, так как регистр - тот самый буфер. И опять таки одно может быть оптимизировано до другого компилятором. То же самое относится к декременту и составному оператору вычитания и присваивания.
также быстрей, чем
, а
- чем
, а если x и o целые, то даже чем
и тоже из-за двух копирований, но
оптимизируется до CODE]x:=x*n;[/CODE] оптимизируется до
, а
и
- до
. Опять таки если в языке уже есть составные операторы, то можно их сразу использовать, а если их нет, то остаётся полагаться на оптимизатор неизвестного качества. В последнюю очередь назову переувлечение указателями, из перечисленного оно влияет меньше всего. Ив последнюю - не возможность изменения локальных копий параметров и операднов, которые не были объявлены как изменяемые, то есть через которые нельзя вернуть значения. Тот же факториал
Код: Выделить всё
unsigned long long int f(unsigned short int n)
{
unsigned long long int r;
for (r=1; n>0; --n)
{
r*=n;
}
return r;
}
на одну операцию быстрей, чем
Код: Выделить всё
unsigned long long int f(unsigned short int n)
{
unsigned long long int r;
unsigned short int i;
for (r=1, i=n; i>0; --i)
{
r*=n;
}
return r;
}
. А если язык не допускает таких вольностей в отношении локальных копий? Если любой параметр эквивалентен или переданному по обычной ссылке, или переданному по константной ссылке? И это только то, валяется на "поверхности". А ведь есть и нюансы, известные только разработчикам оптимизаторов и не факт, что оптимизатор в компиляторе того же фортрана одного качества с плюсовым, это разные программы, писанные
разными программистами. Кстати, явные именованные ссылки могут быть хоть как то полезны ровно в двух случаях:
1. Параметры и операнды.
2. Присваивание переменной значения функции, возвращающей ссылку, или такого же операнда в тех случаях, когда требуется зафиксировать адрес, к которому происходит обращение, но функция/оператор может возвращать ссылку на новую функцию/переменную при каждом обращении.
В остальных случаях они безтолку усложняют текст.
Может быть любая ссылка - надстройка над указателем.
Стандарт требует, чтоб любая ссылка вела себя, как
если бы была надстройкой над указателем (хотя чёрт его знает, может и другими словами это формулирует). Но
стандарт не требует именно такой реализации абсолютно всех ссылок.
