Есть ли обратная сторона в объявлении переменных с auto в 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к типу спасителя и отключают свой мозг при его использовании, либо б) забывают, что это 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. В этом примере кода, взятого из этого вопроса, вы получите обычный (неконстантный) итератор :

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Сам по себе не имеет недостатков , и я рекомендую (осторожно) использовать его везде в новом коде. Это позволяет вашему коду постоянно проверять тип и избегать тихой нарезки. (Если Bпроисходит от, Aи функция, возвращающая Aвнезапно, возвращает B, тогда autoведет себя как ожидалось, чтобы сохранить свое возвращаемое значение)

Хотя унаследованный код до 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 беззнаковых целых, то вы теряете возможность контролировать это.

Как я описал в этом ответе, 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.