Чому я не можу визначити функцію всередині іншої функції?

Question 1

Це не питання лямбда-функції, я знаю, що можу призначити лямбда змінній.

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

Наприклад:

#include <iostream>

int main()
{
    // This is illegal
    // int one(int bar) { return 13 + bar; }

    // This is legal, but why would I want this?
    int two(int bar);

    // This gets the job done but man it's complicated
    class three{
        int m_iBar;
    public:
        three(int bar):m_iBar(13 + bar){}
        operator int(){return m_iBar;}
    }; 

    std::cout << three(42) << '\n';
    return 0;
}

Отже, я хочу знати, чому С ++ дозволить те, twoщо здається марним, а threeяке здається набагато складнішим, але забороняє one?

РЕДАГУВАТИ:

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

Question 2

Не очевидно, чому oneзаборонено; вкладені функції були запропоновані давно в N0295, де сказано:

Ми обговорюємо введення вкладених функцій в C ++. Вкладені функції добре розуміються, і їх впровадження вимагає невеликих зусиль ні від постачальників компіляторів, ні від програмістів, ні від комітету. Вкладені функції пропонують суттєві переваги, [...]

Очевидно, що цю пропозицію було відхилено, але оскільки у нас немає протоколів засідань, доступних в Інтернеті, 1993ми не маємо можливого джерела обґрунтування цього відхилення.

Насправді ця пропозиція зазначена у виразах Лямбда та закриттях для C ++ як можлива альтернатива:

Одна стаття [Bre88] та пропозиція N0295 до комітету C ++ [SH93] пропонують додати вкладені функції до C ++. Вкладені функції подібні до лямбда-виразів, але визначаються як оператори в тілі функції, і отримане закриття не може використовуватися, якщо ця функція не активна. Ці пропозиції також не включають додавання нового типу для кожного лямбда-виразу, а натомість реалізують їх більше, як звичайні функції, включаючи дозволяючи спеціальний тип покажчика функції посилатися на них. Обидві ці пропозиції передують додаванню шаблонів до C ++, і тому не згадують про використання вкладених функцій у поєднанні із загальними алгоритмами. Крім того, ці пропозиції не мають можливості скопіювати локальні змінні в закриття, і тому вкладені функції, які вони виробляють, абсолютно непридатні за межами своєї функції, що включає

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

Щодо цієї частини Вашого запитання:

// This is legal, but why would I want this?
int two(int bar);

Бувають випадки, коли це був би корисний спосіб викликати потрібну вам функцію. Проект стандартного розділу C ++ 3.4.1 [basic.lookup.unqual] дає нам один цікавий приклад:

namespace NS {
    class T { };
    void f(T);
    void g(T, int);
}

NS::T parm;
void g(NS::T, float);

int main() {
    f(parm); // OK: calls NS::f
    extern void g(NS::T, float);
    g(parm, 1); // OK: calls g(NS::T, float)
}

Question 3

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

Прикладом використання може бути:

#include <iostream>

int main()
{
    int func();
    func();
}

int func()
{
    std::cout << "Hello\n";
}

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

Question 4

У наведеному прикладі void two(int)оголошення оголошується як зовнішня функція, причому це оголошення є дійсним лише в межах mainфункції .

Це розумно, якщо ви хочете лише зробити ім’я twoдоступним всередині main(), щоб уникнути забруднення глобального простору імен у поточному блоці компіляції.

Приклад у відповідь на коментарі:

main.cpp:

int main() {
  int foo();
  return foo();
}

foo.cpp:

int foo() {
  return 0;
}

немає необхідності у файлах заголовків. компілювати та посилати на

c++ main.cpp foo.cpp

він буде скомпільований і запущений, і програма поверне 0, як очікувалося.

Question 5

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

З точки зору компілятора, наявність оголошення функції всередині іншої функції є досить тривіальним для реалізації. Компілятору потрібен механізм, який дозволить оголошенням усередині функцій обробляти інші оголошення (наприклад, int x;) всередині функції.

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

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

Це залишає питання про те, чим відрізняється вкладена функція. Вкладена функція відрізняється тим, як вона впливає на генерацію коду. У мовах, що дозволяють вкладені функції (наприклад, Pascal), ви зазвичай очікуєте, що код у вкладеній функції має прямий доступ до змінних функції, в яку він вкладений. Наприклад:

int foo() { 
    int x;

    int bar() { 
        x = 1; // Should assign to the `x` defined in `foo`.
    }
}

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

int f() { 
   int x;
   int y;
   x = 1;
   y = x;
   return y;
}

Компілятор (припускаючи, що він не оптимізував зайвий код) може генерувати код для цього приблизно еквівалентно цьому:

stack_pointer -= 2 * sizeof(int);      // allocate space for local variables
x_offset = 0;
y_offset = sizeof(int);

stack_pointer[x_offset] = 1;                           // x = 1;
stack_pointer[y_offset] = stack_pointer[x_offset];     // y = x;
return_location = stack_pointer[y_offset];             // return y;
stack_pointer += 2 * sizeof(int);

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

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

Тепер у тривіальному випадку це не все так страшно - якщо barвін вкладений всередину foo, тоді barможна просто шукати стек у попередньому вказівнику стека, щоб отримати доступ fooдо змінних. Правда?

Неправильно!Ну, бувають випадки, коли це може бути правдою, але це не обов'язково так. Зокрема,bar може бути рекурсивним, і в цьому випадку дане викликbarможливо, доведеться шукати якусь майже довільну кількість рівнів у резервному стеці, щоб знайти змінні оточуючої функції. Взагалі кажучи, вам потрібно зробити одну з двох речей: або ви поміщаєте додаткові дані в стек, щоб він міг здійснити пошук резервної копії стека під час виконання, щоб знайти кадр стека навколишньої функції, або ви фактично передаєте вказівник на фрейм стека навколишньої функції як прихований параметр для вкладеної функції. О, але тут також не обов’язково є лише одна оточуюча функція - якщо ви можете вкласти функції, ви, можливо, можете вкласти їх (більш-менш) довільно глибоко, тому вам слід бути готовими до передачі довільної кількості прихованих параметрів. Це означає, що у вас зазвичай виходить щось на зразок пов’язаного списку кадрів стека з оточуючими функціями,

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

Це складність, якої C уникав, забороняючи вкладені функції. Зараз, безумовно, правда, що нинішній компілятор C ++ - це зовсім інший вид звіра від старовинного компілятора C 1970-х. З такими речами, як множинне віртуальне успадкування, компілятор С ++ у будь-якому випадку повинен мати справу з речами того самого загального характеру (тобто пошук розташування змінної базового класу в таких випадках також може бути нетривіальним). На відсотках, підтримка вкладених функцій не додасть особливої складності поточному компілятору C ++ (а деякі, такі як gcc, вже підтримують їх).

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

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

Question 6

Перше - це визначення функції, і воно не допускається. Очевидно, що wt - це використання розміщення визначення функції всередині іншої функції.

Але інші двійки - це лише декларації. Уявіть, вам потрібно використовувати int two(int bar);функцію всередині основного методу. Але це визначено нижче main()функції, тому оголошення функції всередині функції змушує вас використовувати цю функцію з оголошеннями.

Те саме стосується і третього. Оголошення класів усередині функції дозволяють використовувати клас усередині функції без надання відповідного заголовка або посилання.

int main()
{
    // This is legal, but why would I want this?
    int two(int bar);

    //Call two
    int x = two(7);

    class three {
        int m_iBar;
        public:
            three(int bar):m_iBar(13 + bar) {}
            operator int() {return m_iBar;}
    };

    //Use class
    three *threeObj = new three();

    return 0;
}

Question 7

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

Отже, щоб підсумувати відповідь:

у сучасній C ++ немає цілей для цієї функції (про яку я принаймні знаю), вона тут через зворотну сумісність C ++ - to-C (я припускаю :)).

Завдяки коментарю нижче:

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

Question 8

Насправді є один варіант використання, який можна уявити корисним. Якщо ви хочете переконатись, що викликається певна функція (і ваш код компілюється), незалежно від того, що декларує оточуючий код, ви можете відкрити власний блок і оголосити в ньому прототип функції. (Натхнення походить від Йоханнеса Шауба, https://stackoverflow.com/a/929902/3150802 , через TeKa, https://stackoverflow.com/a/8821992/3150802 ).

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

Ключ у тому, що локальна декларація замінює попередні декларації у внутрішньому блоці, що закриває. Хоча це може спричинити незначні помилки (і, я думаю, це заборонено в C #), його можна використовувати свідомо. Розглянемо:

// somebody's header
void f();

// your code
{   int i;
    int f(); // your different f()!
    i = f();
    // ...
}

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

Question 9

Це не відповідь на питання ОП, а скоріше відповідь на кілька коментарів.

Я не згоден із цими пунктами в коментарях та відповідях: 1, що вкладені декларації нібито нешкідливі, а 2, що вкладені визначення є марними.

1 Основним контраприкладом для передбачуваної нешкідливості вкладених оголошень функцій є сумнозвісний Найбільш неприємний розбір . ІМО поширення плутанини, спричиненого ним, достатньо, щоб виправдати додаткове правило, що забороняє вкладені декларації.

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

private:
inline void bar(int abc)
{
    // Do the repeating operation
}

public: 
void foo()
{
    int a, b, c;
    bar(a);
    bar(b);
    bar(c);
}

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

Question 10

Конкретно відповідаючи на це питання:

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

Тому що розглянемо цей код:

int main()
{
  int foo() {

    // Do something
    return 0;
  }
  return 0;
}

Запитання для дизайнерів мов:

Повинен foo() бути доступним для інших функцій?
Якщо так, то якою має бути його назва? int main(void)::foo()?
(Зверніть увагу, що 2 не було б можливим на мові С, хто створює С ++)
Якщо ми хочемо локальну функцію, у нас вже є спосіб - зробити її статичним членом локально визначеного класу. То чи варто додати ще один синтаксичний метод досягнення того самого результату? Навіщо це робити? Чи не збільшить це навантаження на підтримку розробників компілятора C ++?
І так далі...

Question 11

Просто хотів зазначити, що компілятор GCC дозволяє оголошувати функції всередині функцій. Детальніше про це читайте тут . Також із введенням лямбда до С ++ це питання зараз застаріло.

Можливість оголошувати заголовки функцій всередині інших функцій, я знайшов корисним у наступному випадку:

void do_something(int&);

int main() {
    int my_number = 10 * 10 * 10;
    do_something(my_number);

    return 0;
}

void do_something(int& num) {
    void do_something_helper(int&); // declare helper here
    do_something_helper(num);

    // Do something else
}

void do_something_helper(int& num) {
    num += std::abs(num - 1337);
}

Що у нас тут? В основному, у вас є функція, яку передбачається викликати з main, тож ви робите те, що вперед оголошуєте її як нормальну. Але тоді ви розумієте, що цій функції також потрібна інша функція, яка допоможе їй у тому, що вона робить. Отож замість того, щоб оголошувати цю допоміжну функцію над основною, ви оголошуєте її всередині функції, яка її потребує, і тоді її можна викликати з цієї функції та лише цієї функції.

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

Question 12

Оголошення вкладених функцій дозволено, ймовірно, для 1. Пересилання посилань 2. Щоб мати можливість оголосити вказівник на функції (функції) та обходити інші функції у обмеженому обсязі.

Визначення вкладених функцій заборонені, ймовірно, через такі проблеми, як 1. Оптимізація 2. Рекурсія (вкладені та вкладені визначені функції) 3. Повторне входження 4. Проблеми з паралельним та багатопотоковим доступом.

З мого обмеженого розуміння :)