Чому неможливо побудувати компілятор, який може визначити, чи змінює функція C ++ значення певної змінної?

Я читав цей рядок у книзі:

Неможливо побудувати компілятор, який насправді може визначити, змінить чи не функція C ++ значення певної змінної.

У параграфі йшлося про те, чому компілятор є консервативним під час перевірки на стабільність.

Чому неможливо побудувати такий компілятор?

Компілятор завжди може перевірити, чи змінена переназначена зміна, на неї викликається функція non-const або вона передається як параметр non-const ...

Чому неможливо побудувати такий компілятор?

З тієї ж причини, що ви не можете написати програму, яка визначатиме, чи припиниться будь-яка програма. Це відома як проблема зупинки , і це одна з тих речей, які не піддаються обчисленню.

Щоб було зрозуміло, ви можете написати компілятор, який може визначити, що функція змінює змінну в деяких випадках , але ви не можете написати ту, яка надійно підкаже вам, що функція змінює (або зупинить) змінну (або зупинить) для всі можливі функції.

Ось простий приклад:

void foo() {
    if (bar() == 0) this->a = 1;
}

Як компілятор може визначити, чи лише fooколись перегляне цей код, чи зміниться a? Це чи ні, залежить від зовнішніх умов функції, а саме від виконання bar. Існує більше, ніж доказ того, що проблема зупинки не піддається обчисленню, але це вже добре пояснено у пов'язаній статті Вікіпедії (і в кожному підручнику з теорії обчислень), тому я не намагатимусь пояснити її правильно тут.

Уявіть, такий компілятор існує. Припустимо також, що для зручності вона забезпечує функцію бібліотеки, яка повертає 1, якщо передана функція модифікує задану змінну, і 0, коли функція відсутня. Тоді що повинна друкувати ця програма?

int variable = 0;

void f() {
    if (modifies_variable(f, variable)) {
        /* do nothing */
    } else {
        /* modify variable */
        variable = 1;
    }
}

int main(int argc, char **argv) {
    if (modifies_variable(f, variable)) {
        printf("Modifies variable\n");
    } else {
        printf("Does not modify variable\n");
    }

    return 0;
}

Не плутайте "буде чи не буде змінювати змінну з урахуванням цих входів" для "має шлях виконання, який змінює змінну."

Перший називається непрозорим визначенням предикатів , і вирішити їх не можна - окрім скорочення проблеми, що зупиняється, ви можете просто вказати, що входи можуть надходити з невідомого джерела (наприклад, користувача). Це стосується всіх мов, а не лише C ++.

Останнє твердження, однак, можна визначити, подивившись на дерево розбору, що і роблять усі оптимізуючі компілятори. Причина, яку вони роблять, полягає в тому, що чисті функції (і референтно прозорі функції, для деякого визначення референтно прозорих ) мають всілякі приємні оптимізації, які можна застосувати, як, наприклад, їх легкодоступність або визначення їх значень під час компіляції; але щоб знати, чи функція чиста, ми повинні знати, чи може вона коли-небудь змінювати змінну.

Отже, те, що здається дивним твердженням про C ++, насправді є тривіальним твердженням про всі мови.

Я думаю, що ключове слово "чи змінить функцію C ++ значення певної змінної" чи "буде" буде ". Безумовно, можливо створити компілятор, який перевіряє, чи дозволяється функція C ++ змінювати значення певної змінної, ви не можете з упевненістю сказати, що зміни відбудуться:

void maybe(int& val) {
    cout << "Should I change value? [Y/N] >";
    string reply;
    cin >> reply;
    if (reply == "Y") {
        val = 42;
    }
}

Я не думаю, що потрібно викликати проблему зупинки, щоб пояснити, що ви не можете алгоритмічно знати під час компіляції, чи буде дана функція змінювати певну змінну чи ні.

Натомість досить зазначити, що поведінка функції часто залежить від умов виконання, про які компілятор не може знати заздалегідь. Напр

int y;

int main(int argc, char *argv[]) {
   if (argc > 2) y++;
}

Як компілятор міг із впевненістю передбачити, чи yбуде модифікований?

Це можна зробити, і компілятори роблять це постійно для деяких функцій , це, наприклад, тривіальна оптимізація для простих вбудованих аксесуарів або багатьох чистих функцій.

Що неможливо - це знати в загальному випадку.

Кожного разу, коли є системний виклик або виклик функції, що надходить з іншого модуля, або виклик методу, який може бути перекрито, може статися все, що завгодно, включаючи вороже захоплення від використання деяким хакером переповнення стека для зміни непов'язаної змінної.

Однак вам слід використовувати const, уникати глобалів, надавати перевагу посиланням на покажчики, уникати повторного використання змінних для непов'язаних завдань тощо, що полегшить життя компілятора при здійсненні агресивних оптимізацій.

Для пояснення цього існує кілька способів, одним з яких є проблема зупинки :

У теорії обчислюваності проблема зупинки може бути викладена так: "Давши опис довільної комп'ютерної програми, вирішіть, чи закінчується програма запущена чи продовжує працювати вічно". Це еквівалентно проблемі прийняття рішення щодо даної програми та вводу, чи програма врешті зупиниться під час запуску із цим входом, чи запуститься назавжди.

Алан Тьюрінг довів у 1936 році, що загальний алгоритм вирішення проблеми зупинки для всіх можливих пар програм-введення не може існувати.

Якщо я напишу програму, яка виглядає приблизно так:

do tons of complex stuff
if (condition on result of complex stuff)
{
    change value of x
}
else
{
    do not change value of x
}

Чи xзмінюється значення ? Щоб визначити це, спершу слід було б визначити, чи do tons of complex stuffвикликає деталь стан вогню - чи ще більш базовий, чи зупиняється він. Це те, що компілятор не може зробити.

Дуже здивований, що немає відповіді, що безпосередньо використовувати проблему зупинки! Існує дуже очевидне скорочення від цієї проблеми до проблеми зупинки.

Уявіть, що компілятор міг би визначити, змінила чи не функція значення змінної. Тоді, безумовно, можна було б сказати, чи змінюється наступна функція значення y чи ні, припускаючи, що значення x можна відстежувати у всіх викликах протягом усієї іншої програми:

foo(int x){
   if(x)
       y=1;
}

Тепер для будь-якої програми, яка нам подобається, давайте перепишемо її як:

int y;
main(){
    int x;
    ...
    run the program normally
    ...
    foo(x);
}

Зауважте, що, якщо і лише якщо наша програма змінює значення y, чи вона тоді припиняється - foo () - це останнє, що вона робить перед виходом. Це означає, що ми вирішили проблему зупинки!

Наведене вище зменшення показує нам, що проблема визначення того, чи змінюється значення змінної, принаймні настільки ж важка, як і проблема зупинки. Проблема зупинки, як відомо, є непорушною, тому ця також повинна бути.

Як тільки функція викликає іншу функцію, про яку компілятор не "бачить" джерело, вона або повинна припустити, що змінна змінена, або все може піти не так далі нижче. Наприклад, скажімо, у нас це є у "foo.cpp":

 void foo(int& x)
 {
    ifstream f("f.dat", ifstream::binary);
    f.read((char *)&x, sizeof(x));
 }

і у нас це є у "bar.cpp":

void bar(int& x)
{
  foo(x);
}

Як компілятор може «знати», що xне змінюється (або змінюється, адекватніше) bar?

Я впевнений, що ми можемо придумати щось складніше, якщо це не досить складно.

Загалом неможливо, щоб компілятор визначив, чи буде змінена змінна , як було зазначено.

Під час перевірки стійкості питання, як видається , викликає інтерес, чи може змінна може бути змінена функцією. Навіть це важко в мовах, які підтримують покажчики. Ви не можете керувати тим, що інший код робить із вказівником, він навіть може бути прочитаний із зовнішнього джерела (хоча малоймовірно). У мовах, що обмежують доступ до пам’яті, такі види гарантій можуть бути можливими і дозволяють зробити більш агресивну оптимізацію, ніж це робить C ++.

Щоб зробити питання більш конкретним, я пропоную наступний набір обмежень, який, можливо, мав на увазі автор книги:

1. Припустимо, що компілятор вивчає поведінку певної функції стосовно стійкості змінної. Для коректності компілятору доведеться припустити (через псевдонім, як пояснено нижче), якщо функція, яка називається іншою функцією, змінна змінена, тому припущення №1 застосовується лише до фрагментів коду, які не здійснюють виклики функції.
2. Припустимо, що змінна не змінюється асинхронною чи одночасною активністю.
3. Припустимо, компілятор визначає лише те, чи змінна може бути змінена, а не чи буде вона змінена. Іншими словами, компілятор виконує лише статичний аналіз.
4. Припустимо, компілятор розглядає лише правильно функціонуючий код (не враховуючи перевитрат / підробок масиву, погані покажчики тощо)

В контексті дизайну компілятора, я думаю, припущення 1,3,4 мають ідеальний сенс у погляді письменника-компілятора в контексті правильності ген коду та / або оптимізації коду. Припущення 2 має сенс у відсутності мінливого ключового слова. І ці припущення також зосереджують питання достатньо, щоб зробити судження про запропоновану відповідь набагато більш виразним :-)

З огляду на ці припущення, основна причина, чому не можна припустити стабільність, пов'язана із змінним псевдонімом. Компілятор не може знати, чи інша змінна вказує на змінну const. Згладжування може бути пов’язане з іншою функцією в тому ж блоці компіляції; у цьому випадку компілятор може переглядати всі функції та використовувати дерево викликів, щоб статично визначити, що може відбуватися випробовування. Але якщо псевдонім пов'язаний з бібліотекою чи іншим іноземним кодом, тоді у компілятора немає можливості дізнатися при введенні функції, чи є змінні псевдонімом.

Ви можете стверджувати, що якщо змінна / аргумент позначена const, то вона не повинна підлягати зміні через псевдонім, але для письменника-компілятора це досить ризиковано. Для людського програміста навіть може бути ризиком оголосити const змінної як частину, скажімо, великого проекту, де він не знає поведінки всієї системи, або ОС, або бібліотеки, щоб дійсно знати, що змінена перемогла ' t змінити.

Навіть якщо оголошена змінна const, це не означає, що якийсь неправильно написаний код може її замінити.

//   g++ -o foo foo.cc

#include <iostream>
void const_func(const int&a, int* b)
{
   b[0] = 2;
   b[1] = 2;
}

int main() {
   int a = 1;
   int b = 3;

   std::cout << a << std::endl;
   const_func(a,&b);
   std::cout << a << std::endl;
}

вихід:

1
2

Для розширення моїх коментарів, текст цієї книги незрозумілий, що заплутує проблему.

Як я коментував, ця книга намагається сказати: "давайте отримаємо нескінченну кількість мавп, щоб написати кожну можливу функцію C ++, яку можна було б коли-небудь записати. Будуть випадки, коли ми виберемо цю змінну (якусь певну функцію написали мавпи) використовує, ми не можемо визначити, чи змінить функцію цю змінну. "

Звичайно, для деяких (навіть багатьох) функцій у будь-якій програмі це може бути визначено компілятором, і це дуже легко. Але не для всіх (або обов'язково більшості).

Цю функцію можна легко проаналізувати:

static int global;

void foo()
{
}

"foo" явно не змінює "глобальний". Він взагалі нічого не модифікує, і компілятор може це зробити дуже легко.

Цю функцію неможливо так проаналізувати:

static int global;

int foo()
{
    if ((rand() % 100) > 50)
    {
        global = 1;
    }
    return 1;

Оскільки дії "foo" залежать від значення, яке може змінюватися під час виконання , воно очевидно не може бути визначене під час компіляції чи буде воно модифікувати "глобальне".

Всю цю концепцію зрозуміти набагато простіше, ніж комп'ютерні вчені. Якщо функція може робити щось інше на основі того, що речі можуть змінюватися під час виконання, тоді ви не можете розробити те, що вона буде робити, доки вона не запуститься, і кожен раз, коли вона запускається, вона може робити щось інше. Незалежно від того, неможливо це чи ні, очевидно неможливо.