Чи стає більш поширеним сучасний C ++? [зачинено]

Коли я вперше дізнався C ++ 6-7 років тому, то, що я дізнався, було в основному "C з класами". std::vectorбезумовно, була розширеною темою, про що ви могли б дізнатися, якщо цього дуже хотіли. І напевно ніхто не сказав мені, що деструкторів можна використовувати, щоб допомогти в управлінні пам’яттю. Сьогодні скрізь, де я дивлюся, я бачу RAII і SFINAE, STL та Boost і, ну, Modern C ++. Навіть люди, які тільки починають працювати з мовою, схоже, навчаються цим поняттям майже з першого дня.

Моє запитання - це просто тому, що я бачу лише "найкращих", тобто питань тут на SO та інших веб-сайтах програмування, які, як правило, приваблюють початківців (gamedev.net), або це насправді представник С ++ спільнота в цілому?

Чи справді сучасний C ++ стає типовим? Замість того, щоб бути якоюсь вигадливою справою, про яку пишуть експерти, це стає "таким, яким просто є C ++"? Або я просто не в змозі побачити тисячі людей, які досі вивчають "C з класами" і записують свої власні динамічні масиви замість того, щоб використовувати std::vectorта керувати пам’яттю, вручну викликаючи новий / видаляти зі свого коду верхнього рівня?

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

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

Ось як я думаю, що все розвинулося.

Перше покоління програмістів C ++ були програмістами C, які насправді використовували C ++ як C з класами. Плюс, STL ще не був на місці, тому C ++ по суті був.

Коли вийшов STL, то просунуті речі, але більшість людей писали книги, складали навчальні програми та навчальні класи спочатку засвоїли C, потім ці додаткові C ++ речі, тому друге покоління навчилося з цієї точки зору. Як зазначається ще одна відповідь, якщо вам зручно писати звичайні петлі, зміна на використання std::for_eachне купує вас багато, крім теплого нечіткого відчуття, що ви робите речі «сучасним» способом.

Тепер у нас є викладачі та письменники, які використовують цілий C ++, і отримують їхні вказівки з тієї точки зору, як-от прискорений C ++ від Koenig & Moo та новий підручник Stroustrup. Тож ми не вчимося char*тоді std::strings.

Це цікавий урок про те, як довго потрібно замінити "застарілі" методи, особливо коли вони мають ефективність.

Абсолютно так. Для мене, якщо ви не програмуєте C ++ у цьому стилі "Сучасний C ++", як ви називаєте, тоді використовувати C ++ немає сенсу! Ви можете просто використовувати C. "Сучасний C ++" повинен бути єдиним способом, коли C ++ коли-небудь запрограмований, на мою думку, і я би сподівався, що всі, хто використовує C ++ і програмував у цій "сучасній" моді, погодиться зі мною. Насправді я завжди повністю шокований, коли чую про програміста на C ++, який не знає таких речей, як auto_ptr або ptr_vector. Наскільки я переживаю, ці ідеї є основними та основними для C ++, і тому я не могла це уявити іншим способом.

За часів Windows 3.1 C був стандартом. Коли C ++ потрапив на ринок розробників і згодом став стандартом ANSI, це була нова гарячість. Він популяризував абревіатуру ООП та деякі основні шаблони дизайну за допомогою поліморфізму.

Тепер, з більш широким прийняттям керованих платформ з низьким рівнем бар'єру для входу, як-от C # /. NET, є менше причин використовувати C ++. Тож значна частина розробників матиме вибір, і будьмо чесними: C ++ - ведмідь, щоб навчитися для новачків. З C # ви можете просто працювати з ним.

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

Так, так, я вважаю, що "Сучасний C ++", як ви заявляєте, стає все більш поширеним. Хоча це і переважає інша аудиторія, ніж раніше.

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

Але розмовляючи з друзями, я також зазначив, що деякі компанії все ще працюють із "C з класами", а не з "Сучасним C ++". Можливо, культура, запропонована авторами та користувачами "Сучасного С ++", колись переможе :)

Я думаю, що у вас просто поганий досвід починався.

Вам потрібно придбати ефективні книги С ++ про Скотта Майєрса . Я з гніву розпочав C ++ в 1999 році, керівництво моєї команди змусило мене сидіти і читати ефективні C ++ та більш ефективні C ++, перш ніж мені дозволили перевірити будь-який код.

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

Якщо ви будете дотримуватися його порад, напишіть хороший або "Сучасний" C ++.

Зараз у нього є книга про STL, але я її не читав.

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

Я навчився C ++ спочатку як щось на зразок C з класами; хоча мова просунулася далеко за рамки цього, книги, які я читав, і люди, з якими я працював, були міцно приклеєні до "старого С ++". RAII щось, про що люди думають, а не роблять автоматично, і я пам'ятаю, читаючи деякі перші статті про проблеми безпеки виключень.

Як зазначалося, зараз з’явилися нові книги. Багато старих залишаються актуальними, але все частіше вони здаються сповненими пояснень, чому очевидно погані ідеї погані. (Аналогічно сучасним читачам важко зрозуміти, наскільки революційними були ідеї Фрейда про несвідомий розум, оскільки зараз це звичайна мудрість.)

Щойно вийшов Stroustrup з підручником, Програмування: Принципи та практика використання C ++ . Я купив його, тому що я ще не зміг навчитися хорошим речам із книги Струструпа, але не пройшов останні кілька глав. Поки все, що я можу сказати, це те, що я схвалюю те, як він починає, і це, принаймні, хороший вступ до того, як слід використовувати C ++.

Під час роботи над проектом, яким я зараз займаюся, існує чимало коду С ++, який розвинувся протягом значного періоду часу (зараз уже понад 10 років). Еволюція, про яку ви говорите, там добре видно: старший код часто "C з класами" - необроблені покажчики, char*рядки та використання пов'язаних з ними функцій C, масивів тощо; новіший код використовує інтелектуальні покажчики ATL та подібні для управління ресурсами, але все ще більшу частину часу дотримується ручно кодованих циклів, і ітератор - це рідкісне видовище; а найновіший - набивний STL контейнерами, алгоритмами,shared_ptr(включаючи власні делетери для керування ручками тощо), сильно генеризовані шаблони функцій та класів тощо. У більшості традиційних методів кодування "C з класами", таких як необроблені некапсульовані покажчики з ручним управлінням життям, сьогодні дуже сильно нахмурюються в оглядах коду. Судячи з цього, здається, що ваше спостереження є точним.

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

Я б не сказав, що std :: vector сьогодні кваліфікується як "сучасний". Це дійсно базово.

Взагалі моє враження, що люди набули певного досвіду в сучасному стилі C ++ і трохи процвіли. Для того, щоб взяти простий приклад, STL for_each було цікавим, але на практиці це не додає великої вартості для простого циклу C. Це важче налагодження і іноді не забезпечує найкращої продуктивності. Також конструкції для функціонального програмування в поточній STL, як правило, дуже громіздкі, особливо якщо ви маєте досвід з реальної функціональної мови, такої як ML.

На мій досвід (Іспанський університет), на жаль, норма полягає в тому, щоб не вважати мовою саме по собі. Вони використовують найпростіші мови для навчання програмуванню (тобто Java), тому що це, як викладачам і студентам, повинно бути простим, а потім вони використовують C для класів ОС тощо.

C ++ вводиться дуже незначно (у будь-якому випадку на будь-якому курсі), просто щоб забезпечити C класами. Вони не вступають у прискорення або навіть STL. Я думаю, що йти в ногу з усіма характеристиками та способом мислення C ++ - це дорого і вчителям, і студентам. Скільки тут програмістів на C ++ знають достатньо всіх бібліотек Boost, щоб використовувати їх для кращого рішення або для його розробки? Треба бути зацікавленим у ногу з усіма новими бібліотеками та ідіомами.

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

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

З повагою,

На мій досвід, це значною мірою залежить від віку програмного продукту / проекту. Більшість нових проектів, які мені відомі, використовують сучасні C ++ (RAII, STL, Boost). Однак є багато проектів C ++, яким більше 10 років, і ви не бачите сучасних C ++.

Також майте на увазі, що деякі з найпопулярніших реалізацій STL були майже порушені до 5 років тому (MSVC <7.0 та GNU <3,00)

Я думаю, що найбільший бар'єр, з яким я стикався, - це підтримка ланцюжків інструментів, особливо для міжплатформних проектів. Ще кілька років тому було звичайно бачити нотатки побудови, які говорять: "x платформа потребує роботи STLport, оскільки їх компілятор захищений". Навіть зараз я бачу проблеми з людьми, які намагаються використовувати кілька сторонніх залежностей, прив'язаних до різних версій BOOST. Це робить зв’язок неможливим, це означає, що ви повинні повернутися назад і відновити свої депа з нуля.

Тепер, коли майже всі перестали використовувати MSVC ++ 6, безлад STLport позаду нас. Але як тільки TR1 з'явиться у дверях, ми повернемося до того, "які версії середовища яких підтримують його і правильно це зробимо", і це ще раз уповільнить прийняття.

Я працюю над проектом, розпочатим у C (а не C ++) у 1992 році. Розгортання сучасних практик у застарілій базі коду було б неможливим. Так само я працюю над іншим проектом, який набагато ближче до передової мови мови C ++.

Багато команд, з якими я брав участь і чули, вважають великим "ми використовуємо винятки?" питання. Це код "ми використовуємо сучасний C ++?"

Після того, як ви не використовуєте винятків, ви не можете використовувати всю потужність мови та її бібліотек.

Але багато старих баз кодів не мають винятків, і вважається, що важко підключити винятки до кодової бази, яка їх не очікує, або в команду, яка не знає, як ними користуватися, тому відповідь у таких випадках - часто «ні».

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

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

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

Для мене "Modern C ++"! = "Метапрограмування шаблонів". Я б сказав, що функції C ++ поверх C потрапляли б у такі категорії:

• Класи (конструктори, деструктори, RAII, динамічне лиття та RTTI)
• Винятки
• Список літератури
• Структури даних та алгоритми в стандартній бібліотеці (STL)
• іострими
• Прості шаблони класів та функцій
• Метапрограмування шаблонів

Жоден із них не є особливо сучасним, оскільки їх було майже 10 чи більше років. Більшість цих функцій корисні і дозволять бути більш продуктивним, ніж прямий C у багатьох випадках використання. Хороший програміст повинен і буде використовувати їх усіх у пристойному проекті, але одна з цих речей не схожа на іншу:

Метапрограмування шаблонів.

Коротка відповідь на метапрограмування шаблонів - просто сказати «ні». На жаль, для деяких людей це синонім до "Сучасного програмування на C ++", завдяки книзі, але врешті-решт це створює більше проблем, ніж вирішує. Якщо C ++ не розробить більш загальні механізми програмування, такі як відображення, він буде погано підходить для загального програмування, а мови вищого рівня, такі як Python, будуть краще підходити для тих випадків використання. З цієї та багатьох інших причин див. FQA C ++

Найкраща книга для вивчення C ++. "Прискорений C ++" від Koenig & Moo вчить те, що ви описуєте як сучасний C ++, тож я здогадуюсь, що більшість людей в ці дні цим користуються. Для тих із нас, хто використовує C ++ досить довгий час (з середини 80-х років у моєму випадку), сучасний C ++ - це велике полегшення від набридливих завдань написання власних масивів, рядків, хеш-таблиць (повторити рекламу нудоти).

Я переглянув C ++ Jobs і справді, і "сучасні" бібліотеки все більше і більше використовуються в описах завдань, MFC, що є досить "старовинним" бібліотекою c ++, використовується менше.

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

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

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

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

Комп'ютерна техніка також зробила значні стрибки з 1990-х, тоді пам'ять і процесор вже не є обмеженням для компілятора. Тож тепер можлива більшість теоретичних оптимізацій із книг.

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

Так і ні. Безумовно, для нових проектів вона стає все більш популярною. Однак існують перешкоди на шляху прийняття, які є практичними, а не політичними, про які інші не згадували. Існує багато комерційних бібліотек C ++, які використовують ABI від стародавніх компіляторів, які не підтримують належним чином функції, які бачать у Modern C ++, і багато компаній покладаються на ці бібліотеки. Наприклад, Sun Studio на Solaris не може працювати з Boost без використання STLport, але будь-яка стороння комерційна бібліотека, яку ви хочете використовувати, потребуватиме версії STL для Sun. Та ж історія з GCC 2.95 та Redhat Enterprise Linux.

Дивовижно, наскільки мало зусиль потрібно зробити C ++ більш стабільним. Система попередження діє, але вона не сильно розвивається. Ще простіше стріляти собі в ногу, ніж це було 10 років тому. Не знаю чому, але c ++ все ще є моєю улюбленою мовою. :)