- 1. Висновок
Світ програмування на C++ в нових стандартах дозволяє нам витворювати різні речі, завдяки яким можна спокійно відмовлятися від деяких старих тверджень або принципів, або просто гнучко підходити до цих принципів.
Хотілося б викласти свій погляд на роботу ідіоми RAII і стандарту C++11 щодо одного принципу авторство якого приписується Едсгеру Дейкстре :
> «модуль (в даному випадку функція) повинен мати лише одну точку входу та лише одну точку виходу»
>
>
Для даного принципу численні return у функції/методі суперечать принципам структурного програмування з наступних причин:
- Складність налагодження коду із застосуванням множинних повернень return збільшується з кількістю цих самих return, тобто ніколи не знаєш, коли саме стався вихід із функції або методу об'єкта.
- Складність підтримки коду, коли при початковому погляді на функцію не помітні усі точки визову. Також не відомо, чи виконається код доданий до кінця функції чи ні, особливо, якщо за логікою програми цей код повинен виконуватися завжди. Тобто у випадку з множинними return доведеться впроваджувати цей код перед кожним викликом оператора return.
Але сучасний C++ вже значно змінився з часів Дейкстри та засоби останніх стандартів C++ дозволяють обійти або значно нівелювати вплив причин, що спричинили формулювання принципів структурного програмування.
Одними з таких засобів у C++ можуть бути ідіоми RAII , лямбда функції , і std::function зі стандартної бібліотеки.
>
RAII (Resource Acquisition Is Initialization) Отримання ресурсу є ініціалізація
- програмна ідіома об'єктно-орієнтованого програмування, сенс якої у тому, що з допомогою тих чи інших програмних механізмів отримання деякого ресурсу нерозривно поєднується з ініціалізацією, а звільнення - з знищенням об'єкта.
>
>
Таким чином, завдяки RAII і лямбда-функцій ми зможемо обійти деякі проблеми з множинними return, зокрема з тим, що деякі код повинен завжди викликатися в кінці функції, незалежно від решти логіки коду функції. Але про це ближче до кінця статті.
А зараз подивимося на доводи за та проти використання множинних return.
Першою причиною є те, що зростає складність налагодження програмного коду за наявності множинних return. Але в той же час вже 2018 рік і сучасні налагоджувачі дозволяють визначити за допомогою точок зупинки, звідки вийшло виконання функції, а наявність множинних return до того ж дозволяє значно зменшити вкладеність коду при використанні конструкцій if else . Таким чином можемо отримати компактніший програмний код, що тільки піде на користь розумінню того, що функція робить, незважаючи на наявність множинних return.
Розглянемо на прикладі
Існують дві функції, які викликаються в іншій головній функції та за результатом роботи тих перших двох функцій будується алгоритм роботи головної функції.
bool exampleFunction_1(); bool exampleFunction_2();
Головна функція, написана за принципами структурного програмування
int examlpeFunctionMain()
{
int result = 0;
if (exampleFunction_1())
{
result = 1;
}
else if (exampleFunction_2())
{
result = 2;
}
return result;
}
Якби таких функцій було б більше, то могла б значно зрости вкладеність конструкцій if else, що на користь програмного коду не пішло б.
Тому перепишемо цей код використання множинних return.
int examlpeFunctionMain()
{
if (exampleFunction_1()) return 1;
if (exampleFunction_2()) return 2;
return 0;
}
Код став значно компактнішим і очевидно, що набагато зрозумілішим. Тобто використання кількох точок виходу із функції може дозволити навпаки покращити код, а не ускладнити його.
А тепер наведемо аргументи про те, що одна точка виходу буде кращою в тому випадку, якщо потрібно, щоб певний програмний код наприкінці функції завжди викликався, а якщо використовувати кілька точок виходу, то дублювати цей код і додавати його перед усіма точками виходу. Наприклад, таким кодом може бути логування результату роботи функції.
Розглянемо приклад такого аргументу.
int examlpeFunctionMain()
{
int result = 0;
if (exampleFunction_1())
{
result = 1;
}
else if (exampleFunction_2())
{
result = 2;
}
std::cout << "Logging result " << result << std::endl;
return result;
}
Наприкінці представленої вище функції є деякий код, що емулює логування. Тоді за наявності кількох точок зупинки цей код доведеться дублювати, і наш попередній гарний варіант стане ось таким негарним.
int examlpeFunctionMain()
{
if (exampleFunction_1())
{
std::cout << "Logging result " << 1 << std::endl;
return 1;
}
if (exampleFunction_2())
{
std::cout << "Logging result " << 2 << std::endl;
return 2;
}
std::cout << "Logging result " << 0 << std::endl;
return 0;
}
Як бачите тут мало того, що кількість рядків зросла на одну, так ще з'явилася можливість припуститися помилки при виконанні копіювання, якщо забути змінити цифру у виведенні логування.
Подібний аргумент за наявність лише однієї точки виходу із функції стає цілком розумним.
Але пропоную тепер звернутись до сучасних можливостей мови програмування C++.
Ідіом RAII має на увазі, що при знищенні об'єкта в деструкторі можна звільнити пам'ять, а також виконати якийсь програмний код. Таким кодом можливо виконання код логування. Але ж у нас немає жодних подібних об'єктів? Так, зараз немає, але пропоную написати клас для використання такого об'єкта.
Це буде шаблонний клас ScopExit. Розглянемо його нижче.
#ifndef SCOPEEXIT_H
#define SCOPEEXIT_H
#include <functional>
class ScopeExit
{
public:
template<typename T>
explicit inline ScopeExit(T&& onScopeExitFunction) :
m_onScopeExitFunction(std::forward<T>(onScopeExitFunction))
{
}
inline ~ScopeExit()
{
m_onScopeExitFunction();
}
private:
std::function<void()> m_onScopeExitFunction;
};
#endif // SCOPEEXIT_H
Клас має приватне поле std::function, це поле відповідатиме за зберігання необхідного нам методу, який виконає код наприкінці виконання функції.
У конструкторі класу дане поле ініціалізується переданим шаблонним аргументом, який може бути функцією або функцією лямбда.
У деструкторі класу ця функція викликається. Тобто коли об'єкт знищуватиметься, буде викликана функція, яку ми помістимо в об'єкт даного класу під час його створення.
З використанням даного класу можна буде переписати вище поданий код таким чином:
int examlpeFunctionMain()
{
int result = 0;
ScopeExit scopeExit([&result](){ std::cout << "Logging result " << result << std::endl; });
if (exampleFunction_1()) return (result = 1);
if (exampleFunction_2()) return (result = 2);
return 0;
}
Сенс цього код полягає в тому, що є змінна результат, яка зберігатиме код, з яким завершиться виконання функції.
Далі створюється об'єкт класу для ScopeExit, який при завершенні методу буде знищений і викличе деструктор лямбду.
Ця лямбда передається як аргумент у конструктор класу ScopeExit. При цьому лямбда захоплює змінну результат, щоб отримати актуальний код завершення функції.
Далі виконуються перевірки та функція завершується в одній із трьох точок виходу, повертаючи значення коду завершення функції. Що важливо, лямбда функція виконається незалежно від того, де завершилося виконання функції. А значить, і логування гарантовано буде виконано незалежно від того, забули його прописати чи ні.
Висновок
Даний приклад штучний і можна забути присвоїти значення змінної result, але якщо потрібно просто виконати якийсь програмний код незалежно від того, де відбулося завершення функції, то цей варіант цілком підходить. А значить і твердження про те, що певний код може бути не виконаний наприкінці функції також втрачає підставу.
Загалом дотримуватися усталених принципів розробки - це добре, але їх придумали багато років тому, а засоби розробки зробили крок вже вперед. Тому потрібно просто добре вивчати свою мову програмування та думати головою. Оскільки багато проблем розробки, які були 20 років тому, зараз можуть бути витончено вирішені засобами програмування.
