Чому я б вивчив C ++ 11, знаючи C і C ++? [зачинено]

Я програміст на C і C ++, хоча не дотримуюся жодної мови і пишу суміш цих двох. Іноді наявність коду в класах, можливо, з перевантаженням оператора, або шаблонами, і так великий STL, очевидно, кращий спосіб. Іноді використання простого покажчика функції С набагато зрозуміліше і зрозуміліше. Тож я знаходжу красу та практичність на обох мовах. Я не хочу вступати в дискусію "Якщо ви їх змішуєте і компілюєте з компілятором C ++, це вже не мікс, це все C ++". Я думаю, що ми всі розуміємо, що я маю на увазі під їх змішуванням. Крім того, я не хочу говорити про C vs C ++, це питання стосується C ++ 11.

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

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

Візьмемо для прикладу С. Після стількох років у C. все ще багато людей навчаються та пишуть код. Чому? Бо мова гарна. Хороший засіб полягає в тому, що він дотримується багатьох правил для створення гарної мови програмування. Окрім того, що є потужним (який легкий чи важкий, майже всі мови програмування), C є регулярним і має невеликі винятки, якщо такі є. C ++ 11, однак, я не думаю. Я не впевнений, що зміни, внесені в C ++ 11, покращують мову.

Тож питання: Чому я б вивчив C ++ 11?

Вам слід це навчитися, якщо ви думаєте, що вам потрібно буде це знати в майбутньому, щоб отримати роботу. Якщо ви впевнені, що ви залишатиметесь проданою у робочій силі як C / C ++ [і все, що ви ще можете знати], тоді не навчіться цього. Якщо ваш начальник скаже вам використовувати C ++ 11, скажіть "ні, я цього не роблю". Якщо він тебе звільнить, піди працювати кудись інше. Вивчіть C ++ 11, коли ви передбачите, що незабаром ви не зможете знайти задовільну роботу за допомогою навичок, які ви зараз знаєте.

Хотів уточнити моє обґрунтування: я не анти-C ++ 11. Просто кажучи, що ви можете узагальнити питання ОП до "Чому я повинен вчитися X". Я ніколи не вивчав ML, схему чи haskell, тому що маю роботу з C та C ++. Я впевнений, що ці мови комусь корисні, але мені зараз не вигідно навчатись. Якщо хтось запропонував мені хороші гроші на програму в ML, я б спробував це навчитися.

Це просто. C ++ 11 робить код значно простішим, чистішим для запису та швидшим.

nullptr- це покращення VAST порівняно зі старим 0. Він безпечний для типу і не конвертує, коли не повинен - ​​на відміну від 0. Це гарна річ, яка nullptrне перетвориться на int. Це взагалі не має сенсу. Чи знаєте ви, що виявив Комітет C ++, коли вони намагалися розглянути #define NULL nullptr? Начебто речі char c = NULL;. Наскільки це жахливо? Єдиною причиною тут є виняток, оскільки boolвін вважається цілісним типом, що є цілком неправильним, але це було в C ++ і раніше, і в C. Те, що nullptrне перетворює, добре , це чудово, і ви повинні його любити.

А як щодо рецензійних посилань та варіативних шаблонів? Швидше, більш загальний код. Це загальний виграш саме там.

Як щодо покращення бібліотеки? Такі речі function, unique_ptrі shared_ptrнастільки кращі, ніж те, що було раніше, неможливо стверджувати, що шлях C ++ 03 був кращим.

#define adding_func(x, y) ((x)+(y))

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

#define add_twice(x) (x + x)

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

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

У функціональному API, наприклад, алгоритмах STL, посилання є чудовим. Якщо це збережений зворотний дзвінок, то вам потрібно зробити захоплення за значенням. Будь-яка документація, яку ви маєте на цю функцію, повинна чітко вказувати, що необхідно. Те, що код написано в лямбда, не має значення для проблеми посилання на локальні змінні - якщо ви передасте звичайний об’єкт функції, то у вас виникнуть такі самі проблеми. І це не біда. Зовсім. Тому що по суті очевидно, коли можна і не можеш посилатися на локальні змінні.

Візьмемо для прикладу С. Після стількох років у C. все ще багато людей навчаються та пишуть код. Чому?

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

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

Якщо взяти C або старий стиль C ++, ви не знайдете багатьох винятків.

Як щодо жалюгідних масивів у стилі С для простого прикладу? Кількість людей, які не можуть отримати масиви та вказівники прямо в голову, нецензурна. Не кажучи вже про те, що бібліотека C Standard неймовірно небезпечна.

Ваші основні аргументи сповнені логічних помилок та непорозумінь.

C ++ 11 - це не нова мова; це лише розширення / модифікація C ++, які ви вже знаєте. C ++ 11, як і будь-яка інша мова програмування, складається з функцій. Дуже багато їх було там раніше, деякі з них - нові. Але ваше запитання насправді полягає в тому, чи варто мені вивчити всі особливості мови (в даному випадку C ++ 11) чи лише ознайомитись з 90% її?

ІМО, навіть якщо ви не використовуєте всю мову, вам слід хоча б прочитати інформацію про те, що нові функції роблять для вас. Багато з них було введено для полегшення запису бібліотечного / фреймворкового коду (особливо шаблонів) (наприклад, раніше, ніж ідеальне переадресація C ++ 11 було неможливим), але якщо раніше у вас не було потреби в цій функції, швидше за все, ви виграєте Не помічаю, що ці функції були додані в C ++ 11.

З іншого боку, якщо ви раніше заперечували над написанням бібліотеки / основного коду, який імітує деякі функції STL / Boost, і ви опинилися обмеженими мовою, тому що ви на 95% отримали дуже круте, елегантне рішення, але потім вас зупинили, оскільки ви з'ясували, що мова просто не підтримує те, що ви хочете, ви зрозумієте справді надзвичайну силу C ++ 11. З тих пір, як наша команда перейшла до VS2010 (і ми виявили Boost в процесі), мені вдалося викрутити якийсь божевільний дивовижний код, який був би неможливим до таких речей, як посилання на значення r та пересилання параметрів шаблону.

Також такі речі, як лямбда, можуть виглядати іноземними, але вони не вводять нову конструкцію. Натомість вони роблять те, що ми мали раніше, набагато простіше писати. Раніше кожна лямбда-функція повинна була бути окремим класом. Тепер це просто {... код ...}. Любіть це.

Ключовим моментом є не дивитись на ці функції, а думати, як страшний список. Натомість використовуйте C ++, як зазвичай, і коли ви натрапите на якийсь сценарій, коли ці нові функції C ++ 11 стануть у нагоді (більше 90% людей ніколи не дістаються до цього моменту), ви будете дуже щасливі, що розширення до мови було зроблено. Наразі я пропоную вам просто вивчити достатньо мови, щоб знати, що там є, а не обов’язково, як ними всім користуватися.

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

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

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

Є приємна розмова Герб Саттера про лямбда, можливо, він може переконати вас краще:

http://channel9.msdn.com/events/PDC/PDC10/FT13

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

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

#define add_func (x, y) ((x) + (y))

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

template<class Lhs, class Rhs>
auto adding_func(const Lhs &lhs, const Rhs &rhs)
                -> decltype(lhs+rhs) {return lhs + rhs;}

Я згоден, це некрасиво. Однак я пам’ятаю, що я казав, «чому, до біса, я мушу визначити тип цього виразу, навіть якщо компілятор може зробити це висновком?». у багатьох випадках. Це може дуже допомогти в ці моменти.

Підсумовуючи:

Незважаючи на те, що нові функції C ++ 11 здаються некрасивими у своєму синтаксисі, я думаю, що до них можна звикнути за короткий час. Кожен новий мовний конструкт спочатку важко вивчити; уявіть, як ви вперше навчилися писати цілий клас: Поклавши декларацію у файл заголовка, не забувши в кінці зайву крапку з комою, поклавши визначення у вихідний файл, включаючи файл заголовка, гарантуючи, що в ньому є захист для запобігання декілька включень, не забуваючи оператора роздільної здатності в деклараціях про функцію-члена і так далі ...

Але я впевнений, що, написавши кілька класів, ви звикаєте до цього, і не думаєте про складність цього процесу: Тому що ви знаєте, що клас робить вашу роботу програміста набагато простішою, а корисність вам Ви заробляєте на цій новій конструкції набагато більше, ніж втрати утиліти за час, коли Ви намагалися вивчити мову . Я думаю, що це може бути причиною, чому варто спробувати навчитися або використовувати C ++ 11 подібним чином.

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

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

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

Вам все це треба навчитись? Так, тому що всі функції - добре чи погано, рано чи пізно - використовуються. Чи добре це для мовної «якості» (якщо визнати, що існує об’єктивна міра для неї) - це інша історія: як довго повинна зберігатися відстала сумісність? важко знайти відповідь, коли хтось скаже 3 роки, а хтось інший каже 50.

Альтернатива зберегти C ++ більш "регулярно" - це ... ламати його частіше, з перезапуском нуля. Але це вже не буде C ++.

Існують спроби зробити це також (подумайте, наприклад, D: набагато більше ортогональних, як C ++ (навіть 11) насправді), але наскільки вони популярні? Одним із причин їх важкого набрання імпульсу є несумісність із багатьма існуючими кодами, які ще мають працювати.

Для мене C ++ 11 - це явно компроміс між новими потребами та зворотною сумісністю. Це призвело до певної «брудності» його технічних характеристик та реалізації. Поки вартість цього "безладу" не буде меншою, ніж вартість несумісності ... вам доведеться піти з цим компромісом.

Якщо ви більше не можете терпіти, ... краще розглянути іншу молодшу мову. C ++ просто не може бути спрощена в цьому сенсі. Не в цьому віці.

Навіть якщо ви вирішите проігнорувати нові функції C ++ 11, ви все одно отримаєте користь від них, оскільки Стандартна бібліотека C ++ їх використовуватиме. Наприклад, у C ++ 98, що має змінну типу, vector<string>потенційно було катастрофою продуктивності через кількість копій, які потрібно зробити, коли вектор зростає. З конструктором переміщення C ++ 11 це не проблема. Насправді, я б хотів, щоб C ++ 11 приніс нам більше нових можливостей, а не менше - особливо в Стандартній бібліотеці.

Після стількох років у C. все ще багато людей навчаються та пишуть код. Чому? Бо мова гарна.

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

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

• Асамблея створена тому, що людям не подобалося писати машинний код
• C був створений тому, що людям не подобалося писати збірки
• C ++ створено тому, що людям не подобалося писати на C
• C ++ 11 створено, тому що людям не подобалося писати C ++

Ви збираєтесь підійти до точки своєї C ++ кар'єри, де ви скажете собі: "Я впевнений, що бажаю, щоб функтори були простішими" або "Чому NULL є цілим?" і тоді ви зрозумієте C ++ 11.

Навчання завжди вигідно. Знання це сила.

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

Один із прикладів - власне запитання. Ви навіть не могли б це запитати, не дізнавшись хоч трохи.

І як я коментував - справжня турбота не в тому, щоб вчитися, а чому використовувати . І це зовсім інше питання.

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

C ++ 11 підтримує окремі поняття "переміщення" та "копіювання". У звичайному C ++ у нас просто є оператор =, який в основному робить і те, і інше. Але насправді ми висловлюємо дві окремі ідеї з одним оператором, що небезпечно.

Найбільш очевидний приклад, де це корисно, - новий унікальний_птр. Він має всі найкращі характеристики старого auto_ptr та scoped_ptr. Припустимо, ми хочемо мати вказівник, який гарантовано є єдиним вказівником, що вказує на об'єкт. Як ми маємо справу з a = b? Ну, перед тим, як ми застрягли, ви могли або заборонити його повністю (як scoped_ptr), або ми могли зробити те, що робить auto_ptr, коли a = b викрадає право власності з b. Така поведінка auto_ptr є дуже заплутаною, оскільки a = b насправді змінюється b. унікальний_ptr вирішує це: a = b заборонено, але у вас є = std :: move (b), щоб викрасти право власності. Чим це корисно? Там, де існує окрема (перевантажена) версія swap, яка використовує семантику переміщення, а не семантику копіювання. Це означає, що той унікальний_птр можна поміняти, без проблем. Це означає, що unique_ptr, на відміну від auto_ptr, безпечно використовувати в контейнері, а потім сказати сортування. unique_ptr - це в основному безпечне управління пам'яттю "все" та "закінчення", коли вам не потрібно декілька покажчиків на один об'єкт.

Ще один чудовий приклад: припустимо, у вас є об'єкт, який неможливо скопіювати. Це корисно в ряді ситуацій. Ви ніколи не можете повернути цей об’єкт з функції, оскільки після завершення функції він копіює все, що ви повертаєте. Іронічна річ у тому, що зазвичай компілятор насправді оптимізує це (тобто насправді нічого не копіюється, повернене значення створюється за адресою можливого призначення). Але це не має нічого спільного з тим, чому ми зробили його неможливим для копіювання; повернення з функції насправді просто переміщення об'єкта зсередини області функцій на зовнішню. Тепер ви можете записувати об'єкти, які не можна скопіювати, але ARE є рухомими, і ці об’єкти можна повернути з функцій.

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