Функции Pure/const в С++

Ответ 1

Я ожидал бы выход:

Я бы ожидал ввода:

int bar(int x) {
   return foo(x) * 100;
}

Ваш код действительно выглядит странным для меня. Как сторонник, я думаю, что либо foo действительно имеет побочные эффекты, либо, скорее всего, переписывает его непосредственно на вышеуказанную функцию.

Как это работает на практике? Если я отмечаю такие функции, как pure/const, может ли он сломать что-либо (учитывая, что код верен)?

Если код верен, то нет. Но шансы на правильность вашего кода малы. Если ваш код неверен, эта функция может маскировать ошибки:

int foo(int x) {
    globalmutex.lock();
    // complicated calculation code
        return -1;
    // more complicated calculation
    globalmutex.unlock();
    return x;
}

Теперь, учитывая панель сверху:

int main() {
    cout << bar(-1);
}

Это заканчивается с помощью __attribute__((const)), но взаимоблокировки в противном случае.

Это также сильно зависит от реализации. Например:

void f() {
    for(;;) 
    {
        globalmutex.unlock();
        cout << foo(42) << '\n';
        globalmutex.lock();
    }
}

Где компилятор должен переместить вызов foo(42)? Разрешено ли оптимизировать этот код? Не в общем! Поэтому, если цикл не является тривиальным, у вас нет преимуществ от вашей функции. Но если ваш цикл тривиален, вы можете легко его оптимизировать самостоятельно.

EDIT: поскольку Альберт попросил менее очевидную ситуацию, вот он: F или пример, если вы реализуете operator << для ostream, вы используете ostream:: sentry, который блокирует буфер потока. Предположим, вы вызываете pure/const f после, который вы отпустили, или до, вы заблокировали его. Кто-то использует этот оператор cout << YourType(), а f также использует cout << "debug info". По вашему мнению, компилятор может поместить вызов f в критический раздел. Выполняется взаимоблокировка.

Ответ 2

Я подумываю об использовании чистых/const-функций в моем коде на С++.

Это скользкий склон. Эти атрибуты нестандартные, и их преимущество ограничено в основном микро-оптимизацией.

Это не хороший компромисс. Вместо этого напишите чистый код, не применяйте такие микрооптимизации, если вы не профилировали тщательно, а theres нет. Или совсем нет.

Обратите внимание на то, что в принципе эти атрибуты довольно хороши, потому что они явно подразумевают предположения о функциях как для компилятора, так и для программиста. Это хорошо. Однако существуют и другие методы, позволяющие сделать подобные предположения явными (включая документацию). Но поскольку эти атрибуты нестандартны, у них нет места в нормальном коде. Они должны быть ограничены очень разумным использованием в критичных по производительности библиотеках, где автор пытается исправить лучший код для каждого компилятора. То есть, писатель знает о том, что только GCC может использовать эти атрибуты и сделал разные варианты для других компиляторов.

Ответ 3

Вы можете определенно нарушить переносимость вашего кода. И почему вы хотите реализовать свой собственный умный указатель - изучение опыта отдельно? Разве их недостаточно для вас в (близких) стандартных библиотеках?

Ответ 4

Я думаю, что никто не знает этого (за исключением gcc-программистов) просто потому, что вы полагаетесь на undefined и недокументированное поведение, которое может меняться от версии к версии. Но как насчет этого:

#ifdef NDEBUG \
    #define safe_pure __attribute__((pure)) \
#else \
    #define safe_pure \
#endif

Я знаю, что это не совсем то, что вы хотите, но теперь вы можете использовать атрибут pure, не нарушая правил.
Если вы хотите узнать ответ, вы можете спросить на форумах gcc (список рассылки, что угодно), они должны быть в состоянии дать вам точный ответ.
Значение кода: Когда определен NDEBUG (символ, используемый в макросах assert), мы не отлаживаем, не имеем побочных эффектов, можем использовать чистый атрибут. Когда он определен, у нас есть побочные эффекты, поэтому он не будет использовать чистый атрибут.

Ответ 5

Я бы рассмотрел сгенерированный asm, чтобы узнать, какая разница. (Мое предположение заключалось в том, что переход от потоков С++ к чему-то другому принесет большую пользу, см. http://typethinker.blogspot.com/2010/05/are-c-iostreams-really-slow.html)