C ++ 11: новый язык? - PullRequest
31 голосов
/ 07 мая 2009

Недавно я начал читать (чуть чуть) текущий черновик для будущего стандарта C ++ 11.

Существует множество новых функций, некоторые из которых уже доступны в Boost Libs. Конечно, я очень доволен этим новым стандартом, и я хотел бы поиграть со всеми новыми функциями как можно скорее.

Во всяком случае, говоря об этом проекте с некоторыми друзьями, давними разработчиками C ++, возникли некоторые проблемы. Итак, я прошу вас (ответить на них):

1) Сам язык

Это обновление огромно, возможно, слишком велико для отдельного стандартного обновления. Огромный для поставщиков компиляторов (даже если большинство из них уже начали реализовывать некоторые функции), но также и для конечных пользователей.

В частности, мой друг сказал мне: « это своего рода новый язык ».

  • Можем ли мы считать это новым языком после этого обновления?
  • Планируете ли вы перейти на новый стандарт или идти в ногу со "старыми" стандартами?

2) Знание языка

  • Как новый стандарт повлияет на кривую обучения?
  • Преподавать язык будет сложнее?
  • Некоторые функции, хотя и довольно удивительные, кажутся мне слишком «академичными» (как я имею в виду, определение). Я не прав?
  • Освоение всех этих новых дополнений может быть кошмаром, не так ли?

Ответы [ 11 ]

18 голосов
/ 07 мая 2009

Короче говоря, нет, мы не можем считать это новым языком. Это тот же язык, новые функции. Но вместо того, чтобы использовать библиотеки Boost, они теперь будут стандартными включениями, если вы используете компилятор, который поддерживает стандарт 0x.

Нельзя иметь для использования нового стандарта при использовании компилятора, который поддерживает новый стандарт. Однако придется изучить и использовать новый стандарт, если существуют определенные ограничения на разрабатываемое программное обеспечение, но это ограничение для любого программного обеспечения. Я думаю, что новые функции, которые стандарт 0x сделает , облегчат выполнение определенных задач и будут менее подвержены ошибкам, поэтому полезно узнать, что представляют собой новые функции и как они улучшат свою стратегию проектирования для будущая работа. Нужно также изучить его, чтобы при работе с программным обеспечением, разработанным с его помощью, они понимали, что происходит, а не делали большие бу-бу-бу.

Относительно того, буду ли я " переходить на новый стандарт ", если это означает, что я буду изучать новый стандарт и использовать его там, где это применимо, и там, где он повысит мою производительность, тогда да, я определенно планирую на переключатель . Однако, если это означает, что я ограничу себя только работой с новыми функциями стандарта 0x, то нет, так как большая часть моей работы связана с кодом, написанным до стандарта, и это было бы колоссальной задачей перепроектировать все, чтобы использовать новые функции. Мало того, это может привести к появлению новых ошибок и проблем с производительностью, о которых я не знаю без опыта.

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

Овладение языком является долгосрочной целью, это невозможно сделать за ночь. Глупо думать, что можно быстро овладеть чем-то таким сложным, как C ++. Требуются практика, опыт и отладка кода, чтобы действительно что-то вбить. Академическое обучение - это одно, а использование этих знаний - совсем другое чудовище. Я думаю, что если кто-то уже владеет языком C ++, новые концепции не будут слишком обременительными, но у новичка может быть преимущество в том, что он не потрудится изучить некоторые из более устаревших способов ведения дел. .

15 голосов
/ 07 мая 2009

1) Сам язык

Насколько я знаю, действительно нет серьезных изменений между C ++ '03 и C ++' 0x. Единственное, что я могу придумать, касается использования auto как спецификатор класса хранения, но так как он не имеет семантической то есть я не вижу в этом проблемы.

Есть много других академических исправлений к стандарту, которые очень необходимо, например, лучшие описания для макета члена данные. Наконец, когда многоядерные / процессорные архитектуры становятся нормой, исправление модели памяти было обязательным.

2) Знание языка

Лично я чувствую, что для 99,9% разработчиков C ++ более новый язык будет проще в использовании. Я специально думаю о таких функциях, как авто, лямбда и constexpr. Эти функции действительно должны сделать использование языка более приятным.

На более продвинутом уровне у вас есть другие функции, такие как variadic шаблоны и т. д., которые помогают более продвинутым пользователям.

Но здесь нет ничего нового, я все еще удивлен количеством обычные разработчики C ++, которые не использовали (или даже не слышали) о STL.

С личной точки зрения, единственная особенность, которая меня немного беспокоит в новом стандарте, - это концепции. Поскольку это такое большое изменение, те же проблемы, которые возникли с шаблонами (то есть полностью сломанными реализациями), представляют реальную опасность.

Обновление поста FDIS для голосования:

Как это происходит, «концепции» были отброшены для C ++ 0x и будут снова рассмотрены для C ++ 1x. В конце концов есть некоторые изменения, отличные от auto, которые могут нарушить ваш код, но на практике они, вероятно, будут довольно редки Основные различия можно найти в Приложении C.2 FDIS (pdf) .

12 голосов
/ 07 мая 2009

Для меня одним из самых важных будет:

unique_ptr + std :: move ()!

Представьте себе:

  1. Умный указатель без каких-либо накладных расходов:

    • нет операций подсчета ссылок
    • нет дополнительной памяти для переменной счетчика ссылок
  2. Умный указатель, который можно переместить , т.е. при перемещении не вызывается деструктор / конструктор

Что это тебе дает? Исключительно безопасные, дешевые (указатели ..) контейнеры без каких-либо затрат . Контейнер сможет использовать только memcpy () unique_ptrs, поэтому не будет потери производительности, вызванной переносом обычного указателя умным указателем! Итак, еще раз:

  1. Вы можете использовать указатели
  2. Это будет безопасно (без утечек памяти)
  3. Это вам ничего не будет стоить
  4. Вы сможете хранить их в контейнерах, и они смогут делать «массивные» ходы (подобные memcpy) с ними дешево.
  5. Это будет исключение

:)

Другая точка зрения:

  1. На самом деле, когда вы перемещаете группу объектов с помощью copy (), для каждого экземпляра объекта происходит вызов конструктора и деструктора. Когда вы копируете 1000 объектов размером 1 КБ, произойдет как минимум один вызов функции memcpy () и 2000.
  2. Если вы хотите избежать тысяч звонков, вам придется использовать указатели.
  3. Но указатели опасны и т. Д. Актуальные умные указатели вам не помогут, они решат другие проблемы.
  4. Пока нет решения. Вы должны время от времени платить за дизайн CII RAII / pointer / valuevars. Но в C ++ 0x использование unique_ptr позволит выполнять «массивные» перемещения объектов (да, практически объектов, потому что указатель будет умным) без «массивных» вызовов конструктора / деструктора и без риска использования указателей! Для меня это действительно важно.

Это похоже на ослабление концепции RAII (из-за использования указателей) без потери преимуществ RAII. Другой аспект: указатель, завернутый в unique_ptr (), будет вести себя во многих аспектах подобно переменной ссылочного объекта Java. Разница в том, что unique_ptr () сможет существовать только в одной области за раз.

9 голосов
/ 07 мая 2009

Ваш друг частично прав, но в основном не прав: это тот же язык с дополнительными функциями.

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

Только тогда, когда вы захотите взглянуть на новые функции, вам нужно будет учесть изменения. Это процесс, который вы можете растянуть на годы, если это необходимо.

Мой совет - узнать, какие все новые функции находятся на высоком уровне (хотя бы для того, чтобы быть хорошо осведомленными в собеседованиях при приеме на работу), но изучать детали медленно.

8 голосов
/ 07 мая 2009

В некоторых отношениях C ++ 0x должен быть проще для обучения / изучения, чем текущий C ++:

  • Зацикливание в контейнере - новый синтаксис for намного проще, чем for_each + функтор или зацикливание вручную с помощью итераторов
  • Инициализация контейнеров: мы сможем инициализировать последовательности с тем же синтаксисом, что и для массивов
  • Управление памятью: уходит устарелое старое auto_ptr, входит хорошо определенное unique_ptr и shared_ptr

Лямбда, хотя и более сложная, чем эквиваленты других языков, будет легче освоить, чем процесс определения функциональных объектов в другой области видимости в C ++ 98.

7 голосов
/ 24 мая 2009

У вас есть точка зрения, но так было всегда. Существует много кода на C ++, который все еще не содержит ничего из стандарта '98 только из-за врожденного консерватизма некоторых кодеров. Некоторые из нас помнят темное время перед пространством имен std:: (на самом деле перед пространствами имен), когда каждый писал свой собственный класс строк, и указатели все время ходили голыми. Есть причина, по которой мы говорим о «современном стиле C ++» - чтобы отличать его от более раннего стиля, потому что некоторые люди все еще должны поддерживать или обновлять код в этом стиле.

Любой язык должен развиваться, чтобы выжить, а любой развивающийся язык будет иметь разделенную базу пользователей, хотя бы потому, что люди по-разному относятся к оценке альтернативных издержек при применении новых языковых функций в своей работе.

С появлением C ++ 0x в отгрузочных компиляторах этот разговор будет снова и снова повторяться командами разработчиков по всему миру:

МОЛОДЕЖЬ: Я только что обнаружил такие вещи, как лямбды! И я нахожу множество способов использовать их, чтобы сделать наш код более выразительным! Слушай, я переписал твой старый класс Foo, не так ли аккуратнее?

ОЛДСТЕР: С моим старым классом Фу все было в порядке. Вы просто ищете оправдания ненужному использованию "крутой" новой функции. Почему вы продолжаете пытаться сделать мою жизнь такой сложной? Почему я продолжаю изучать новые вещи? Нам нужна еще одна война, вот что нам нужно.

МОЛОДЕЖЬ: Вы слишком застряли в своих отношениях, старик, мы не должны даже использовать C ++ в наши дни ... если бы это зависело от меня -

ОЛДСТЕР: Если бы это зависело от меня, мы бы застряли с PL / 1, но нет ... моей жене пришлось голосовать за Картера, и теперь мы застряли со всем этим объектно-ориентированным дерьмом. Вы ничего не можете сделать с std::transform и лямбдами, которые я не могу сделать с goto и парой ярлыков.

и т.д.

7 голосов
/ 07 мая 2009

Планируете ли вы перейти на новый стандарт или идти в ногу со "старыми" стандартами?

Год назад я писал строгий C89, потому что рассматриваемый продукт был агрессивно переносим на встраиваемые платформы, некоторые из которых имели компиляторы с радикально отличающимися представлениями о том, какие биты C99 стоит поддерживать. Таким образом, 20-летний стандарт все еще не полностью заменен 10-летним преемником.

Так что я не ожидаю, что смогу в ближайшее время уйти от C ++ 03.

Я ожидаю использовать функции C ++ 0x там, где это необходимо. Так же, как я использую функции C99 в коде C и расширения gcc в C и C ++ (и буду использовать расширения MSVC, хотя я никогда не работал над кодом только для MSVC более чем тривиальные промежутки времени). Но я ожидаю, что это будет "хорошо иметь", а не базовый уровень, в значительной степени на неопределенный срок.

5 голосов
/ 07 мая 2009

Ваша карьера программиста всегда будет включать в себя обучение и переобучение. Вы не можете ожидать, что c ++ останется таким же, пока вы не уйдете на пенсию и будете использовать те же методы и практики, которые вы использовали 40 лет назад. Технология набирает обороты, и она быстро развивается. Это ваша работа, чтобы не отставать от этого. Конечно, вы можете игнорировать это и продолжать работать так же, как в настоящее время, но через 5/10 лет вы станете настолько устаревшими, что вы будете вынуждены изучать все это тогда, когда вы пытаетесь сменить работу , И все эти годы было намного легче учиться на работе:)

4 голосов
/ 07 мая 2009

Несколько месяцев назад я слышал, как Бьярн Страуструп выступил с докладом под названием 50 лет C ++ . Правда, я не программист на C ++, но мне показалось, что он, конечно, не думает, что 0x - это новый язык!

3 голосов
/ 07 мая 2009

Концепции и концептуальные карты значительно улучшат возможности шаблонных фреймворков. Если вы когда-нибудь поливали источник Boost, вы поймете, что я имею в виду. Вы постоянно переходите от исходного документа к документу, потому что у языка просто нет возможности выразить концепции шаблона. Надеемся, что Concepts + Duck Typing предоставит нам лучшее из обоих миров, благодаря которым точки входа в библиотеки шаблонов могут явно декларировать требования, но при этом обладают свободой, которую предоставляет Duck Typing при написании общего кода.

В C ++ 0x есть много хороших вещей, но в основном это эволюционные изменения, которые улучшают или расширяют существующие идеи. Я не думаю, что это достаточно отличается, чтобы оправдать называть это «новым языком».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...