Скільки коштує занадто багато ключових слів C ++ 11?

Я використовую нове autoключове слово, доступне в стандарті C ++ 11, для складних шаблонових типів, для чого я вважаю, що він був розроблений. Але я також використовую його для таких речей, як:

auto foo = std::make_shared<Foo>();

І більш скептично:

auto foo = bla(); // where bla() return a shared_ptr<Foo>

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

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

Побічна примітка: це питання було переміщено до SE.Programmers, а потім назад до переповнення стека. Обговорення цього питання можна знайти в цьому мета-питанні .

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

my_multi_type::nth_index<2>::type::key_type::composite_key_type::
    key_extractor_tuple::tail_type::head_type::result_type

щоб отримати тип складеного ключа boost::multi_index, навіть якщо ви знаєте, що це int. Ви не можете просто писати, intтому що це може бути змінено в майбутньому. Я б писав autoу цьому випадку.

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

Ось кілька прикладів:

auto foo = std::make_shared<Foo>();   // obvious
auto foo = bla();                     // unclear. don't know which type `foo` has

const size_t max_size = 100;
for ( auto x = max_size; x > 0; --x ) // unclear. could lead to the errors
                                      // since max_size is unsigned

std::vector<some_class> v;
for ( auto it = v.begin(); it != v.end(); ++it )
                                      // ok, since I know that `it` has an iterator type
                                      // (don't really care which one in this context)

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

Легко. Використовуйте його, коли вам все одно, що це за тип. Наприклад

for (const auto & i : some_container) {
   ...

Мене тут все хвилює - це те i, що є в контейнері.

Це трохи схоже на typedefs.

typedef float Height;
typedef double Weight;
//....
Height h;
Weight w;

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

Або розглянути

for (auto i = some_container .begin (); ...

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

Також тип лямбда не може бути написаний, так auto f = []...це хороший стиль. Альтернативою є кастинг, std::functionале це поставляється з накладними витратами.

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

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

Контрприклади (запозичені з чужих відповідей):

auto i = SomeClass();
for (auto x = make_unsigned (y); ...)

Тут ми НЕ дбаємо, що це за тип, тому ми повинні писати Someclass i;іfor(unsigned x = y;...

Действуй. Використовуйте autoбудь-де це полегшує написання коду.

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

Але якби я працював над кодом з більш ніж декількома подібними рядками

auto foo = bla();

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

На C ++ та за її межами 2012 року на панелі « Запитайте у нас все» відбувся фантастичний обмін між Андрієм Олександреску, Скоттом Мейєрсом та Герб Саттером, який говорив про те, коли користуватися, а не використовуватиauto . Перехід до хвилини 25:03 для 4-хвилинної дискусії. Всі три динаміки дають чудові бали, про які слід пам’ятати, коли їх не використовувати auto.

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

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

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

Перефразовуючи те, що Герб сказав, "якщо ви не робите X, Y і Z, використовуйте auto. Дізнайтеся, що таке X, Y і Z, і продовжуйте користуватися autoскрізь."

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

   for(auto i = container.begin(); i != container.end(); ++i);

auto тут не шкодить читабельності.

Інший приклад - тип правила парсера, який може бути довгим і складним. Порівняйте:

   auto spaces = space & space & space;

з

r_and_t<r_and_t<r_char_t<char>&, r_char_t<char>&>, r_char_t<char>&> spaces = 
   space & space & space;

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

int i = foo();

а не

auto i = foo();

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

auto A = Matrix(...);
auto B = Matrix(...);
auto C = A * B; // C is not a matrix. It is a matrix EXPRESSION.
cout << C; // The expression is evaluated and gives the expected result.
... // <code modifying A or B>
cout << C; // The expression is evaluated AGAIN and gives a DIFFERENT result.

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

auto C = Matrix(A * B); // The expression is now evaluated immediately.

Я використовую autoобмеження wihout і не зіткнувся з жодною проблемою. Я навіть іноді в кінцевому підсумку використовую його для таких простих типів int. Це робить c ++ мовою вищого рівня для мене і дозволяє оголошувати змінну в c ++, як у python. Після написання пітонного коду я навіть іноді пишу, наприклад

auto i = MyClass();

замість

MyClass i;

Це один випадок, коли я б сказав, що це зловживання autoключовим словом.

Часто я не заперечую, який саме тип об’єкта, мене більше цікавить його функціональність, і як назви функцій взагалі говорять щось про об’єкти, які вони повертають, autoне шкодить: наприклад auto s = mycollection.size(), я можу здогадатися, що sце буде якесь ціле число, і в рідкісному випадку, коли я дбаю про точний тип, давайте перевіримо прототип функції тоді (я маю на увазі, я вважаю за краще перевірити, коли мені потрібна інформація, а не апріорі, коли пишеться код, просто на випадок, коли б це було корисно колись, як в int_type s = mycollection.size()).

Щодо цього прикладу з прийнятої відповіді:

for ( auto x = max_size; x > 0; --x )

У своєму коді я все-таки використовую autoв цьому випадку, і якщо я хочу xбути без підпису, то я використовую функцію утиліти з назвою сказати make_unsigned, яка чітко висловлює мою стурбованість:

for ( auto x = make_unsigned(max_size); x > 0; --x )

відмова від відповідальності: я просто описую своє використання, я не компетентний давати поради!

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

Просто для ілюстрації цього розглянемо нижче програму c ++:

int main() {
    int x;
    int y = 0;
    y += x;
}

Якщо я компілюю цю програму за допомогою сучасного компілятора (GCC), вона дає попередження. Таке попередження може бути не дуже очевидним, якщо ми працюємо з реальним складним виробничим кодом.

main.cpp: У функції 'int main ()':

main.cpp: 4: 8: попередження : 'x' використовується неініціалізованим у цій функції [-Вінваліталізований]

y + = x;

    ^

===================================================== ================================ Тепер, якщо ми змінимо нашу програму, яка використовує автоматичне , то компілюючи ми отримуємо наступне:

int main() {
    auto x;
    auto y = 0;
    y += x;
}

main.cpp: У функції 'int main ()':

main.cpp: 2: 10: error : оголошення "auto x" не має ініціалізатора

 auto x;

      ^

При автоматичному використанні неініціалізованої змінної неможливо. Це головна перевага, яку ми можемо отримати (безкоштовно), якщо почнемо використовувати авто .

Цю концепцію та інші великі сучасні концепції C ++ пояснив експерт C ++ Herb Shutter у своїй розмові про CppCon14 :

Назад до основ! Основи сучасного стилю C ++

Одна з загроз, яку я зазначив, стосується посилань. напр

MyBigObject& ref_to_big_object= big_object;
auto another_ref = ref_to_big_object; // ?

Проблема в іншому_ref насправді не є посиланням, в цьому випадку це MyBigObject замість MyBigObject &. Ви копіюєте великий об'єкт, не усвідомлюючи цього.

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

auto another_ref = function_returning_ref_to_big_object();

вам знадобиться "auto &" або "const auto &"

MyBigObject& ref_to_big_object= big_object;
auto& another_ref = ref_to_big_object;
const auto& yet_another_ref = function_returning_ref_to_big_object();

Використовуйте autoтам, де є сенс для виводу типу. Якщо у вас є щось, для якого ви знаєте, що це ціле число, або ви знаєте, що це рядок, просто використовуйте int / std :: string тощо. Я б не турбувався про "надмірне використання" мовної функції, якщо це не стане смішним, або обтяжує код.

Це все-таки моя думка.

autoключове слово можна використовувати лише для локальної змінної, а не для аргументів або членів класу / структури. Отже, користуватися ними можна де завгодно безпечно і життєздатно. Я їх дуже багато використовую. Тип виводиться під час компіляції, налагоджувач показує тип під час налагодження, sizeofповідомляє про це правильно, decltypeдав би правильний тип - шкоди немає. Я ніколи не вважаю autoсебе занадто зловживаним!

TL; DR: Див. Правило внизу.

Загальноприйнятий відповідь пропонує наступне правило:

Використовуйте, autoколи важко сказати, як написати тип з першого погляду, але тип правої частини виразу очевидний.

Але я б сказав, що це занадто обмежувально. Іноді я не дбаю про типи, оскільки вислів є досить інформативним, не можу зайняти час, щоб визначити тип. Що я маю на увазі під цим? Розглянемо приклад, який з’явився в деяких відповідях:

auto x = f();

Що робить це прикладом неправильного використання auto? Це моє незнання f()типу повернення? Що ж, це справді може допомогти, якби я це знав, але - це не моя головна турбота. Набагато серйознішою проблемою є те , що xі f()досить безглуздо. Якби у нас були:

auto nugget = mine_gold();

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

Тому моя відповідь: Використовуйте, autoколи компілятор дозволяє, якщо:

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

І також:

• Перед заміною autoконкретним типом віддайте перевагу давати змістовне ім’я (яке не містить імені типу) .

Один з моїх гірких переживань auto- це використання його з лямбда-виразами :

auto i = []() { return 0; };
cout<<"i = "<<i<<endl; // output: 1 !!!

Насправді, тут iвирішено функціонувати покажчик int(*)(). Це просто cout, але уявіть, які помилки компіляції / помилок виконання можуть спричинити при використанні template.

Вам слід уникати auto таких виразів і вводити належний returnтип (або керований decltype())

Правильне використання для наведеного вище прикладу було б,

auto i = []() { return 0; }(); // and now i contains the result of calling the lambda