Становится ли современный C ++ более распространенным? [закрыто]

Когда я впервые изучил C ++ 6-7 лет назад, то, в основном, я выучил «Си с классами». std::vectorопределенно была сложной темой, о которой вы могли бы узнать, если бы действительно захотели. И, конечно же, никто не говорил мне, что деструкторы можно использовать для управления памятью. Сегодня куда бы я ни посмотрел, я вижу RAII, SFINAE, STL, Boost и, ну, современный C ++. Кажется, что даже люди, которые только начинают изучать язык, обучаются этим концепциям почти с первого дня.

У меня вопрос, это просто потому, что я вижу только «лучшее», то есть вопросы здесь, на SO, и на других сайтах программирования, которые, как правило, привлекают новичков (gamedev.net), или это действительно представитель Сообщество C ++ в целом?

Действительно ли современный C ++ становится стандартом по умолчанию? Специалисты пишут о том, что это не какая-то причудливая штука, становится ли он «таким, каким является C ++»? Или я просто не могу видеть тысячи людей, которые все еще изучают "C с классами" и пишут свои собственные динамические массивы вместо использования std::vector, и управляют памятью, вручную вызывая new / delete из своего кода верхнего уровня?

Как бы мне ни хотелось в это верить, это кажется невероятным, если сообщество C ++ в целом так сильно развилось за несколько лет. Какие у вас впечатления и впечатления?

(отказ от ответственности: кто-то, не знакомый с C ++, может неверно истолковать заголовок как вопрос, набирает ли C ++ популярность по сравнению с другими языками. Это не мой вопрос. «Современный C ++» - это общее название диалекта или стиля программирования в C ++, названного в честь книги » Современный дизайн C ++: применение универсального программирования и шаблонов проектирования », и меня интересует исключительно это, а не« старый C ++ ». Так что не нужно говорить мне, что время C ++ прошло, и мы все должны использовать Python;))

Вот как, я думаю, все развивались.

Первым поколением программистов на C ++ были программисты на C, которые фактически использовали C ++ как C с классами. Кроме того, STL еще не было, так что, по сути, C ++ был именно таким.

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

Теперь у нас есть инструкторы и авторы книг, которые использовали весь C ++ и получали свои инструкции с этой точки зрения, такие как ускоренный C ++ Koenig & Moo и новый учебник Страуструпа. Таким образом , мы не узнаем 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 ++».

Так что да, я считаю, что «современный C ++», как вы его утверждаете, становится все более распространенным. Хотя это распространено среди другой аудитории, чем использовалось в прошлом.

Я один из тех ребят, которые научились работать с STL и много слышали о RAII и хороших практиках программирования на C ++ с первого дня. Похоже, некоторые из наиболее рекомендуемых книг для изучения C ++ сегодня (например, Accelerated C ++ и серия Effective C ++ ) сосредоточиться на использовании инструментов STL вместо того, чтобы собирать свои собственные вещи, а также дать множество «правил» для эффективного (или «современного») программирования.

Но в разговоре с друзьями я также заметил, что некоторые компании все еще работают с «C с классами», а не с «современным C ++». Может быть, культура, предложенная авторами и пользователями «Современного C ++», когда-нибудь возобладает :)

Я думаю, у тебя только что начался неудачный опыт.

Вам нужно приобрести книги Скотта Мейерса « Эффективные C ++». Я начал заниматься C ++ в 1999 году, руководитель моей группы заставил меня сесть и прочитать «Эффективный C ++» и «Более эффективный C ++», прежде чем мне разрешили проверять ЛЮБОЙ код.

Большинство его советов звучит так: «Не используйте эту функцию , но, если необходимо, помните об этом ».

Если вы последуете его совету, вы напишете хороший или «современный» C ++.

У него тоже есть книга по STL, но я ее еще не читал.

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

Изначально я изучал C ++ как что-то вроде C с классами; хотя язык далеко продвинулся вперед, книги, которые я читал, и люди, с которыми я работал, твердо придерживались «старого C ++». RAII - это то, о чем люди будут думать, а не делать это автоматически, и я помню, как читал некоторые из первых статей о проблемах безопасности исключений.

Как уже отмечалось, сейчас есть новые книги. Многие из старых идей все еще актуальны, но они все больше кажутся полными объяснений, почему заведомо плохие идеи плохи. (Точно так же современным читателям трудно понять, насколько революционными были идеи Фрейда о бессознательном, поскольку теперь это общепринятое мнение.)

Страуструп только что выпустил учебник « Программирование: принципы и практика использования C ++» . Я купил его, потому что я еще не упустил возможности выучить хорошие вещи из книги Страуструпа, но еще не прошел первые несколько глав. Пока все, что я могу сказать, это то, что я одобряю то, как он начинал, и, по крайней мере, это хорошее введение в то, как следует использовать 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 ++») тоже не помогает, поскольку это в основном книга по метапрограммированию шаблонов, которая является специфической областью C ++, но ни в коем случае не единственной.

Для меня «Современный C ++»! = «Метапрограммирование шаблонов». Я бы сказал, что возможности C ++ поверх C можно разделить на следующие категории:

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

Ни один из них не является особенно современным, так как все они существуют около 10 или более лет. Большинство из этих функций полезны и позволят вам работать более продуктивно, чем обычный C, во многих случаях использования. Хороший программист должен и будет использовать их все в проекте приличного размера, но одна из этих вещей не похожа на другую:

Метапрограммирование шаблонов.

Короткий ответ на метапрограммирование шаблонов - просто сказать нет. К сожалению для некоторых людей из-за книги это синоним «современного программирования на C ++», но, в конце концов, это создает больше проблем, чем решает. Если C ++ не разработает более совершенные универсальные механизмы программирования, такие как отражение, он будет плохо подходить для общего программирования, а языки более высокого уровня, такие как Python, будут лучше подходить для этих случаев использования. По этой и многим другим причинам см. C ++ FQA.

Лучшая книга для изучения 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.

Удивительно, как мало усилий уходит на то, чтобы сделать С ++ более стабильным. Система предупреждений существует, но не претерпевает значительных изменений. Прострелить себе ногу еще проще, чем 10 лет назад. Не знаю почему, но C ++ по-прежнему мой любимый язык. :)