Kyberman

Какая проверка работает быстрее?

Которая вызывает переход, предсказанный предсказателем переходов (поскольку ветвь по которой пойдет код уйдет в конвеер)

Если в контексте PHP/Python/Ruby то разницы нету вообще, потому что поток команд формируется по мере выполнения и в итоге не особо получится что-то такое разруливать и тут вообще пофигу какое из перечисленных условий вы будете выполнять. А если говорить о java/javascript/c#/c++/etc то тут большее значение имеет то, как часто будет срабатывать одна или другая ветвь кода. Скажем если условие всегда выполняется или не выполняется, то современный процессор будет после первых двух итераций всегда угадывать какая ветвь кода будет грузиться и оверхэда вообще не будет. Не знаю как на AMD но на интеловских так же неплохо работает предсказание того, что ветви будут выполняться по переменно, один раз одна, другой раз другая.

Так что совсем не важно что будет выполняться в условии. Важно что бы это было предсказуемо, поддавалось каким-то шаблонам. И тогда это будет максимально производительно. А сама операция сравнения это одна операция. и не важно какая это будет операция. Намного важнее что бы весь поток команд который идет на выполнение был в кеше процессора.

И да, если это вообще разовое условие то можно просто забить. Это важно только в циклах.

если в потоке только пробельные символы cin >> n их просто проигнорирует, и если дойдет до конца потока, то cin >> n будет интерпретировано как false, собственно, выход и так случится. Мне кажется, что вы не всю проблему рассказали...

Находим серьёзную кросс-платформенную программу с открытыми исходниками, я выбрал Qt Creator.

Заходим в диалог "About" и видим как раз то, что нам нужно:



Находим построение этого диалога в исходном коде - [src/plugins/coreplugin/versiondialog.cpp | 77].

Видим, что для получения даты и времени сборки использованы тривиальные предопредёленные макросы __DATE__ и __TIME__, которые гарантировано должны быть предопределены во всех компиляторах.

А вот для нахождения версии компилятора используется специальная функция ICore::buildCompatibilityString(). Проследуем по цепочке вызовов: [src/plugins/coreplugin/icore.cpp | 472].

В функции ICore::buildCompatibilityString() используется вызов статической функции compilerString() для получения информации о компиляторе и QSysInfo::WordSize для получения информации о битности порождаемого компилятором кода.

Функция compilerString() [src/plugins/coreplugin/icore.cpp | 440-458] выглядит так:

static QString compilerString()
{
#if defined(Q_CC_CLANG) // must be before GNU, because clang claims to be GNU too
    QString isAppleString;
#if defined(__apple_build_version__) // Apple clang has other version numbers
    isAppleString = QLatin1String(" (Apple)");
#endif
    return QLatin1String("Clang " ) + QString::number(__clang_major__) + QLatin1Char('.')
            + QString::number(__clang_minor__) + isAppleString;
#elif defined(Q_CC_GNU)
    return QLatin1String("GCC " ) + QLatin1String(__VERSION__);
#elif defined(Q_CC_MSVC)
    if (_MSC_VER >= 1800) // 1800: MSVC 2013 (yearly release cycle)
        return QLatin1String("MSVC ") + QString::number(2008 + ((_MSC_VER / 100) - 13));
    if (_MSC_VER >= 1500) // 1500: MSVC 2008, 1600: MSVC 2010, ... (2-year release cycle)
        return QLatin1String("MSVC ") + QString::number(2008 + 2 * ((_MSC_VER / 100) - 15));
#endif
    return QLatin1String("<unknown compiler>");
}

Макросы Q_CC_CLANG, Q_CC_GNU и Q_CC_MSVC можно заменить на __clang__, __GNUC__ || __MINGW32__ и _MSC_VER соответственно. Вызовы QLatin1String() можно заменить обычным std::string, QString::number() - чем-нибудь типа sprintf, itoa, std::to_string (если используете c++11).

А QSysInfo::WordSize это простой:

enum Sizes {
        WordSize = (sizeof(void *)<<3)
};

Удачи!

Функция применяется n + 1 раз к n. Для этого надо список из n + 1 функций f свернуть при помощи композиции, а затем применить к аргументу. Добавим ещё fromIntegral, так как в примерах у вас синусы, которым нужно число с плавающей точкой, а n же у вас - целое (функцию можно применить только целое кол-во раз).

execute f n = foldr1 (.) (replicate (succ n) f) (fromIntegral n)

где replicate (succ n) f - список из n + 1 функций f, foldr1 (.) - свёртка списка композицией

Есть и второй вариант, не сворачивать n + 1 функций f через композицию, а сворачивать список, на каждом шаге сразу применяя к аргументу, т.е. так:

execute f n = foldr ($) (fromIntegral n) (replicate (succ n) f)

где ($) - функция применения, т.е. f $ x = f x

нажмите в студии ctrl+F5, введите например "1 2 3 0" без кавычек и нажмите enter ;)

#include <iostream>

void foo()
{
	int number;
	cin >> number;
	if (number != 0)
	{
                //фишка в том что:
		foo(); //сначала выполняется функция 
		cout << number << " "; // а после уже выполняется вывод
	}
}

int main(int argc, char *argv[])
{
	foo();
        return 0;
}

UPD:
1. рекурсия использует стек вызовов и глубина рекурсии зависит от размера этого стека
2. исходя из предыдущего пункта не стоит писать код который выше в продакшене, лучше использовать цикл и массив(или стек) который запрещают
3. обновил сигнатуру main, это никак не должно повлиять на выполнение программы, но так корректнее

вот результат:

haxe + openfl + haxepunk.com или haxeflixel.com
для физики nape.

С точки зрения применимости - нет.

С точки зрения разрыва шаблона в ощущении окружающего мира - да. Вам придется узнать и смирится со столькими откровениями, типа:
Один электрон пролезает в две дырки.
Пока фотон летит, он не существует.
У абсолютного вакуума есть энергия.
Фотон меняет направление своего движения мгновенно.
Ну и т.д.