Чи є недолік у оголошенні змінних з авто в C ++?

Здається, що autoв C ++ 11 було додано досить значну особливість, яка, здається, відповідає багатьом новим мовам. Як і в такій мові, як Python, я не бачив явної декларації змінної (я не впевнений, чи можливо це за допомогою стандартів Python).

Чи є недолік використання autoоголошень змінних, а не явного їх оголошення?

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

Основний недолік полягає в тому, що, використовуючи auto, ви не обов’язково знаєте тип створюваного об'єкта. Також бувають випадки, коли програміст може очікувати, що компілятор виведе один тип, але компілятор невпинно виводить інший.

Дано декларацію на кшталт

auto result = CallSomeFunction(x,y,z);

вам не обов’язково знати знання про тип result. Це може бути int. Це може бути вказівник. Це може бути щось інше. Усі вони підтримують різні операції. Ви також можете різко змінити код незначною зміною

auto result = CallSomeFunction(a,y,z);

оскільки залежно від того, які перевантаження існують для CallSomeFunction()типу результату, можуть бути абсолютно різними - і наступний код може, таким чином, вести себе зовсім інакше, ніж передбачалося. Ви можете раптом викликати повідомлення про помилку в більш пізньому коді (наприклад, згодом намагаєтеся знешкодити int, намагаючись змінити щось, що є зараз const). Більш зловісна зміна полягає в тому, коли ваша зміна проходить повз компілятора, але наступний код веде себе різними і невідомими - можливо, баггі - способами.

Не маючи явних знань про тип деяких змінних, тому ускладнюється жорстке обґрунтування твердження про те, що код працює за призначенням. Це означає більше зусиль для обгрунтування тверджень про «придатність до мети» у областях з високою критичністю (наприклад, критично важливими для безпеки або місією).

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

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

auto x = my_obj.method_that_returns_reference();

На жаль, ми просто глибоко скопіювали якийсь об’єкт. Часто це або помилка, або продуктивність не вдається. Тоді ви можете розмахувати і іншим способом:

const auto& stuff = *func_that_returns_unique_ptr();

Тепер ви отримуєте звисаючу довідку. Ці проблеми взагалі не викликані auto, тому я не вважаю їх законними аргументами проти цього. Але, схоже, autoробить ці питання більш поширеними (з мого особистого досвіду) з причин, які я перерахував на початку.

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

Інші відповіді згадують недоліки на кшталт "ти насправді не знаєш, що таке тип змінної". Я б сказав, що це багато в чому пов'язане з неохайною умовою іменування в коді. Якщо ваші інтерфейси чітко названі, вам не потрібно дбати про те, який саме тип. Зрозуміло, auto result = callSomeFunction(a, b);це вам мало говорить. Але auto valid = isValid(xmlFile, schema);вам достатньо використовувати, validне піклуючись про те, який саме його тип. Зрештою, просто if (callSomeFunction(a, b)), ви також не знали б типу. Те саме з будь-якими іншими тимчасовими об'єктами на вираз. Тому я не вважаю це справжнім недоліком auto.

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

SomeType operator* (const Matrix &lhs, const Vector &rhs);

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

MultExpression<Matrix, Vector> operator* (const Matrix &lhs, const Vector &rhs);

Тепер проблема полягає в тому, що, MultExpression<Matrix, Vector>швидше за все, зберігатимуться внутрішньо const Matrix&і const Vector&внутрішньо; він очікує, що він перетвориться на a Vectorдо кінця свого повноцінного вираження. Якщо у нас є цей код, все добре:

extern Matrix a, b, c;
extern Vector v;

void compute()
{
  Vector res = a * (b * (c * v));
  // do something with res
}

Однак, якби ми autoтут використали , ми могли б потрапити в біду:

void compute()
{
  auto res = a * (b * (c * v));
  // Oops! Now `res` is referring to temporaries (such as (c * v)) which no longer exist
}

Одним з недоліків є те, що іноді ви не можете оголосити const_iteratorз auto. Ви отримаєте звичайний (не const) ітератор у цьому прикладі коду, взятого з цього питання :

map<string,int> usa;
//...init usa
auto city_it = usa.find("New York");

Це робить ваш код трохи важчим або стомлюючим для читання. Уявіть щось подібне:

auto output = doSomethingWithData(variables);

Тепер, щоб з'ясувати тип виводу, вам доведеться відстежити підпис doSomethingWithDataфункції.

Як і цей розробник, я ненавиджу auto. Вірніше, я ненавиджу , як люди зловживають auto.

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

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

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

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

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

autoне має недоліки самі по собі , і я виступаю в (ручному wavily) використовувати його всюди в новому коді. Це дозволяє вашому коду послідовно перевіряти набір тексту та постійно уникати беззвучного нарізання. (Якщо Bпоходить від Aі функція, що повертається Aраптово, повертається B, то autoповодиться так, як очікувалося, зберігає свою повернуту вартість)

Хоча застарілий код pre-C ++ 11 може покладатися на неявні перетворення, викликані використанням явно введених змінних. Зміна явно введеної змінної autoможе змінити поведінку коду , тож вам слід бути обережнішими.

Ключове autoслово просто виводить тип із поверненого значення. Тому він не еквівалентний об'єкту Python, наприклад

# Python
a
a = 10       # OK
a = "10"     # OK
a = ClassA() # OK

// C++
auto a;      // Unable to deduce variable a
auto a = 10; // OK
a = "10";    // Value of const char* can't be assigned to int
a = ClassA{} // Value of ClassA can't be assigned to int
a = 10.0;    // OK, implicit casting warning

Оскільки autoвиводиться під час компіляції, він не матиме недоліків під час виконання.

Те, про що тут ніхто не згадував, але для себе варто відповісти, якщо ви запитали мене.

Оскільки (навіть якщо всі повинні знати про це C != C++) код, написаний на C, може бути легко сконструйований таким чином, щоб забезпечити базу для коду C ++ і, отже, бути спроектований без особливих зусиль для сумісності з C ++, це може бути вимогою до проектування.

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

Але autoвперше ¹ це змінюється!

Уявіть, що ви раніше використовували autoяк специфікатор класу зберігання та передавали код. Це навіть не обов'язково (залежно від способу його використання) "зламати"; це фактично могло мовчки змінити поведінку програми.

Це те, про що слід пам’ятати.

¹ _{Принаймні, я вперше про це знаю.}

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

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

Ще один дратівливий приклад:

for (auto i = 0; i < s.size(); ++i)

створює попередження ( comparison between signed and unsigned integer expressions [-Wsign-compare]), оскільки iце підписаний int. Щоб цього уникнути, потрібно написати напр

for (auto i = 0U; i < s.size(); ++i)

а може й краще:

for (auto i = 0ULL; i < s.size(); ++i)

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

void test (const int & a)
{
    // b is not const
    // b is not a reference

    auto b = a;

    // b type is decided by the compiler based on value of a
    // a is int
}

Гарне використання

Ітератори

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int> v();

..

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int>::iterator it = v.begin();

// VS

auto vi = v.begin();

Функції Покажчики

int test (ClassWithLongName1 a, ClassWithLongName2 b, int c)
{
    ..
}

..

int (*fp)(ClassWithLongName1, ClassWithLongName2, int) = test;

// VS

auto *f = test;

Погане використання

Потік даних

auto input = "";

..

auto output = test(input);

Функція Підпис

auto test (auto a, auto b, auto c)
{
    ..
}

Тривіальні випадки

for(auto i = 0; i < 100; i++)
{
    ..
}

Я здивований, що ніхто про це не згадував, але припустимо, ви що-небудь обчислюєте:

#include <iostream>
using namespace std;

int main() {
    auto n = 40;
    auto factorial = 1;

    for(int i = 1; i <=n; ++i)
    {
        factorial *= i;
    }

    cout << "Factorial of " << n << " = " << factorial <<endl;   
    cout << "Size of factorial: " << sizeof(factorial) << endl; 
    return 0;
}

Цей код виведе це:

Factorial of 40 = 0
Size of factorial: 4

Це, безумовно, не був очікуваним результатом. Це сталося тому, що було autoвиведено тип змінної факториалу, intтому що він був призначений 1.