148,19
рейтинг
16 января 2013 в 14:13

Разработка → C++ в 2013 году перевод

2013 год только начинается. Чего же мы можем ожидать в нём для языка С++?

Ещё в прошлом году стало заметно значительное оживление в мире С++. Язык становится более динамичным, это заметно. С++03 правил много лет, без нового cтандарта С++ почти целое десятилетие мы наблюдали за развитием библиотек, статического программирования, вещей типа мета-программирования на шаблонах — и всё это неплохо эволюционировало. Но вот сам язык при этом никуда не двигался.

В 2013 году это изменится. Во-первых, начиная с этого года новый стандарт С++11 наконец станет доступен широкой аудитории, в виду полноценной его поддержке в Visual Studio 2012, Clang 3.2 и GCC 4.8. Влияние нового стандарта на библиотеки и фреймворки ощущается уже сейчас, к примеру многое из него нашло своё применение в Qt5. Но стандарту С++11 не суждено стать фундаментом разработки на следующее десятилетие. Скорее, его можно воспринимать как хороший промежуточный этап, шаг в сторону эволюции языка, которая продолжится в 2013-ом году и позже.

Это одна из причин почему я думаю, что 2013 год станет особенным для С++. В этом году начнется работа над новым стандартом — С++14. В апреле пройдет встреча комитета по стандартизации С++ в Бристоне (Великобритания) и мы уже сможем представить себе наброски будущего стандарта. В октябре пройдет встреча в Чикаго, где должен быть уже сформирован более или менее чёткий черновик, который в начале 2014-го станет новым ISO-стандартом.

Что же нам предложит С++14?

Возможно, работа с файловой системой станет частью стандартной библиотеки. Абсолютно точно в стандарт войдут багфиксы для С++11, такие, к примеру, как вот этот. Возможно, изменения коснуться std::future, поскольку нынешняя реализация с блокировками вызывает некоторые нарекания. Несколько минорных изменений могут коснуться многопоточности. Точнее мы будет знать лишь после апрельской встречи, так что утверждать что-либо пока не имеет смысла.

Как я уже писал в моей статье "Острова С++", сообщество разработчиков С++ весьма разделено, так что на разных «островах» в этом году произойдут разные вещи. С++ станет более важной часть в среде мобильной разработки. Microsoft представила WinRT и Windows Phone 8, под которые вполне можно писать на С++. BlackBerry 10 от RIM предполагает программирование под эту платформу как на чистом С/С++, так и использование Qt для более высокоуровневой разработки. И хотя Nokia отошла от поддержки Qt, на других платформах влияние этого фреймворка только усиливается, так что этот год будет вполне неплохим для Qt. Qt5 гибок, поддерживает С++11 и уже широко распространён в индустрии. Qt5 и QML приходят на Android, iOS, BlackBerry 10, Jolla, Ubuntu Phone а может быть, и на WinPhone 8. Экосистема Qt продолжает расти, развиваемая такими компаниями как Digia, KDAB и ICS.

Говоря о достоинствах Qt и QML, нельзя молчать и об их проблемах: QML страдает от фрагментации в его API, в первую очередь касающейся кросcплатформенности. Это то, работа над чем должна начаться уже прямо сейчас. Программист на Qt должен знать, что написав код единожды, он может рассчитывать на его компиляцию и запуск под любой платформой. В моих глазах это очень большая проблема — я могу сделать элемент Rectangle, который будет выглядеть как прямоугольник на всех платформах, но не могу сделать элемент Button, который будет выглядеть и вести себя как кнопка на всех платформах. На сегодняшний день для этого нужно писать реализацию UI для каждой платформы. К счастью, сообщество уже начало работу над объединённым стандартом, который должен решить проблему фрагментации и я надеюсь, что в результате мы получим надежное и стабильное решение для виджетов QML на всех платформах.

Ещё одним важным направлением развития языка оказался компилятор clang. В конце 2012 года мы стали свидетелями того, как LLVM и clang проникли в индустрию. Embarcadero построили свою новую IDE вокруг clang, Apple также решила его использовать, а Nvidia даже перешла с собственных решений на clang для GPU-вычислений. С выходом версии 3.2 clang стал более стабилен, и вполне возможно, что вскоре он первым сможет похвастаться 100%-ой поддержкой стандарта С++11.

Ещё одним событием, которое способствует развитию С++ и Qt случайно стали проблемы с уязвимостями в Java, которых недавно было найдено сразу несколько. Одним из важных факторов выбора Java раньше была его «безопасность», в сравнении с С++. Прошлый год показал, что столь уж явного и безоговорочного преимущества в безопасности эта платформа не имеет. Некоторые организации даже пришли к решению полностью удалить Java со своих компьютеров. Я не говорю, что С++ в этом плане лучше или безопаснее, но в силу разделения по платформам, библиотекам и компилятором в мире С++ не может быть глобальной проблемы, которая затронет сразу всех.

В 2012 году прошло много хороших С++ конференций по С++. Я думаю, они продолжатся. На подходе ADC++ и Meeting C++, несколько конференций в Америке (С++Now в мае и C++ and Beyond в декабре), также пройдут QtDevDays в Берлине и Калифорнии. Прямо перед встречей комитета по стандартизации С++ пройдет ACCU, где выступит Бьёрн Страуструп и еще несколько докладчиков по С++.

Год обещает быть интересным. Я желают всем вам успехов в нём.
Автор: @tangro meetingcpp

Комментарии (64)

  • +12
    Надеюсь, c++14 не превратится в c++2x :)
    • 0
      Обещают в С++14 ничего радикального не вносить, а существенные изменения на C++17. Так что по идее не должны сильно задержать. Но даты не фиксированные, всё может поменяться.
      • +1
        Это понятно, тут скорее эволюция c++98 -->c++03, чем переход к C++11, но не пройтись по поводу скорости принятия последнего стандарта я не мог :)
  • +8
    Ещё одним событием, которое способствует развитию С++ и Qt случайно стали проблемы с уязвимостями в Java, которых недавно было найдено сразу несколько. Одним из важных факторов выбора Java раньше была его «безопасность», в сравнении с С++. Прошлый год показал, что столь уж явного и безоговорочного преимущества в безопасности эта платформа не имеет.


    Были неоднократные проблемы с браузерным плагином, но тот логический вывод, который автор приводит выглядит весьма нелепым.
    • +5
      1. Проблемы были не только с браузерными плагинами.
      2. Некоторые компании решили вообще поудалять рантайм Java со своих компьютеров. Им неизменно придётся выбирать программы, написанные на чём-то другом, что повышает рейтинг С++

      Автор слегка категоричен (а может даже слегка злорадствует), но он частично прав.
      • +1
        Мне кажется, что автор прав относительно падения привлекательности Java, но ошибается в причинах. Уязвимости были только в браузерах, а в таком виде на Java уже никто не пишет. Намного более серьёзной проблемой является то, что как язык Java стагнирует уже очень давно. А в C++ как раз новый стандарт наделал положительного пиара. Тогда как в Java 8 (будущий релиз) вводят ограниченный type inference (diamond operator), в C++ уже есть нормальный auto.

        Scala немного помогает Java миру, в последнем релизе вот шаблоны добавили. Но это слишком «академический» язык, он вряд ли добьётся массовости и изменит мир.

        Поэтому к C++ возвращается утерянный было образ «cool kid», потом и растёт интерес к нему.
  • +20
    полноценной его поддержке в Visual Studio 2012

    Хорошая шутка ;)
    • 0
      Вы зря не смотрите выступления Херба, он там много всякого рассказывал, и о студии 2012 и о плане апдейтов компилятора отвязанном от общих апдейтов студии.
      • +10
        Выступления, планы и объективная реальность — всё-таки немного разные вещи.

        Да в vs2012 даже банальный std::map<std::string, int> m = { { "a", 1 }, { "b", 2 } }; не компилируется. Вы на количество No и Partial вот здесь смотрели?

        При всей моей любви к vs(основная ide, в которой работаю), я уже давно привык, что от стандартам она частенько не соответствует. И пока не верю, что 2012я будет в этом плане отличаться от предыдущих. Очень хотелось бы оказаться неправым в этот раз…
        • +8
          Перевести бы их на clang всех.
          • 0
            он генерит чуть более тормозной код. Для high performance проектов бывает критично.
            • +1
              Но он потихоньку нагоняет gcc, а там есть ещё интересные штуки типа polly, которые помогут и обогнать. Пока сильно критично отсутствие openMP разве что.
        • +2
          moadib, приведенный Вами код не компилируется в силу того, что на момент выхода November CTP Stephen не успел обновить STL. Когда CTP превратиться в релиз(или RC) то Вы обязательно скомпилируете этот код. Ждать следующей стадии в CTP осталось не долго, я полагаю.
          И Вам не зря указали на выступления Герба; на данный момент Microsoft действительно заинтересовано в скорейшей имплементации стандарта в своём компиляторе. Поэтому есть все основания полагать, что в 2013 году мы увидим полную поддержку стандарта в студии(тем более, что из сложных фич не реализовано только constexpr, насколько я помню)
          • 0
            Как я и написал выше, очень хочу оказаться неправым :)
  • +2
    Ну может они ещё сахарку подкинут помимо auto, было б очень неплохо.
    • +4
      Я бы больше был бы рад, если бы метаинформацию для рефлексии добавили. Чтобы можно было сигналы, слоты и свойства в Qt делать без использования moc'а.
      • 0
        Это да, это было бы круто!
        • 0
          А главное Херб в каком-то выступлении рассказывал, что оно даже можно и лично им вовсе даже не влом — вся информация по этому делу у компилятора есть и он легко мог бы её отдать, надо только сесть и прописать устраивающие всех стандарты. Вот только именно тут и загвоздка.
          • 0
            Можно написать плагин для clang'а и уже по мере его разработки и обкатки прийти к некоторому согласию.
  • +9
    Очень хотелось бы новую модульную систему, надеюсь она не останется на уровне черновика.
    • +1
      Более того, там столько всего менять придётся — ужас. Я на 99% уверен, что модули в С++14 не войдут. Очень уж масштабное изменение.
      • +1
        Кому интересно, то здесь презентация про модули: Modules: Update on work in progress—Doug Gregor. В конце кстати указывается, что модули в clang уже находятся в разработке.
      • +1
        Вот никогда не понимал этого странного желания «ничего не менять», лишь бы не сломать «обратную совместимость». Кто не хочет — пускай юзает старые компиляторы! А нормальные программисты захотят использовать новые и с удовольствием внесут изменения в свой код. А уж модули-то в первую очередь нужно вводить, дурацкую систему инклудов надо было выкинуть еще лет 20 назад.
        • –4
          Да конечно модули — это классно, а инклюды надо было 20 лет как выкинуть. Но сегодня изрядная часть программирования на С++ — поддержка старых проектов. Нового не так уж много стартует на плюсах. И вот для этих старых проектов будет тяжело модули присобачить.
          • +1
            Ну если поддержка старых проектов — то я же предлагаю не переходить на новые компиляторы, «поддержка» — это в лучшем случае исправление ошибок. В крайнем случае, если будут обнаружены ошибки в старом компиляторе, разработчики компиляторов могут выпустить исправленную версию компилятора для старого С++. Но такие случаи крайне редки.
            А те, кто активно развивает проекты, добавляет новую функциональность — перейдут. Я бы с удовольствием перешел бы на модули, если бы они были:) И на рефлексию перешел бы, и на нормальные синтаксические макросы вместо адского «метапрограммирования на шаблонах», и на много чего еще.
          • –1
            Такие как вы и не начинают. А дайте нам то поиграться с чем-то новым. Тем более, что в обозримом будущем пока не видна полноценная замена тройке C++/C/ObjectiveC.
            • 0
              А чего-это вы в меня пальцем тыкаете? Я за последний год минимум несколько проектов начал на плюсах и статей по ним на Хабре написал немало. Другое дело, что у меня на то были причины, а у всё большего количества нынешних проектов (веб, андроид, айос — тренды) этих причин нет.
              • 0
                А на чем тогда вы предлагаете писать кроссплатформенные библиотеки?
                • +1
                  В 90% случаев я предлагаю их не писать, а брать имеющиеся, которых выше крыши. В оставшихся 10% это может быть С, С++ или JAVA (это смотря какие платформы в каждом конкретном случае входят в понятие «кроссплатформенность»).

                  Я не пойму вы отрицаете тот факт, что нынче стартует больше проектов на управляемых\скриптовых языках, чем на С++?
          • 0
            А чем модули могут повредить обратной совместимости? Вводим новую директиву (к примеру #include module «somefile»)

            #include «vector»
            #include module «MeshQuadro.cxx»

            Чтото сорсвиевер хабрі не признает в спп треугольніх скобок.
        • 0
          Посмотрите что творится с проектами, менющами API или стандарт языка постоянно. Ими просто никто не пользуется. Для комерческих пользователей очень важно, чтобы была обратная совместимость. Рефакторить весь код при выпуск на новую версию это слишком дорого.
  • +15
    Статья слишком оптимистична. На самом деле будет так:
    В следующем году начнется работа над новым стандартом — С++21. В апреле 2015 пройдет встреча комитета по стандартизации С++ в Бристоне (Великобритания) и мы уже сможем представить себе наброски будущего стандарта. В октябре 2018 пройдет встреча в Чикаго, где должен быть уже сформирован более или менее чёткий черновик, который в конце 2021-го станет новым ISO-стандартом.
  • +5
    Так приятно слушать хорошее про любимый язык, особенно от пользователей хабра
  • +6
    Начали за здравие (С++14), а закончили за упокой (Qt). То ли автор забыл, что он собирался рассказать про С++14, то ли выделил это целым абзацем просто по невнимательности.
  • +1
    Java безопасна не в том смысле, что нет секьюрити дыр, а в том, что, обращение по непоянтному указателю, или за границы массива приводит не к порче памяти а к тому что просто вылетит ошибка времени выполнения.
    • 0
      Которая точно также приведет к краху приложения. Единственная разница в том, что в си и плюсах при обращении к непонятному указателю таки может «повезти», что таки приведет к появлению странной ошибки или вовсе гейзенбага.
      • +2
        Это исключение можно поймать, и память не поломается. Так вобщем-то обычно и делается. Разница имеено в том что не везет, и Гейзенбергов у нас не бывает. Программировать без этой радости намного удобнее и приятнее.
        • 0
          Если возникло такое искючение, то о штатном продолжении исполнения приложения не может быть и речи.
          Я уже черти сколько ни разу в плюсах такой хрени не ловил.
          • +1
            если вы используете высокоуровневые контейнеры, то да, но если вы где-то заиспользуете низкоуровневый код, то привет. и вам никто не будет гарантировать, что какой-нибудь junior девелопер не возомнит себя кул хацкером и не напишет низкоуровневый код, который раздолбает вам всю систему, а вы будете ловить Гейзенберга,
            • 0
              Никто не гарантирует, что юниор не разломает Java приложение. А вот штуки типа Геррита эту гарантию дают для любого проекта на любом ЯП. А если заапрувил коммит с кулхацкер извращениями, то ССЗБ.
              ru.wikipedia.org/wiki/Gerrit
      • 0
        В си/плюсах можно закорраптить вообще любую доступную приложению память, просто разыменовав dangling pointer. Проделайте-ка это в Java.
  • 0
    Apple также решила его использовать


    LLVM/Clang тем, чем он сейчас является стал при непосредственном участии Apple
  • 0
    Ох щас мне и карму сольют, но скажу — что-то за время штудирования нового стандарта я не заметил ничего такого что позволило-бы сделать мои программы лутше, а вы?
    • +1
      [какой-то текст] лутше [какой-то текст]

      Нет в русском языке такого слова! Вы переменные тоже называете indeks, databeis, tvitter?
      • +1
        О боже — в школе на мове, в университете на русском, по жизни на суржике! Хабра не филологический ресурс — атомного взрыва не случится от слова ЛУТШЕ!
        • 0
          Хабр — для грамотных людей.
          • +1
            Уважаемый Psionic указал на ту же проблему, с которой и я сталкиваюсь — если русский язык не родной, а к тому-же если в школе 11 лет говорил с учителями и одноклассниками на другом языке — выучить русский во взрослом возрасте на уровне жителя России, который занимался этим с детства — нереально. Понятно, что Хабр — для грамотных людей. Но вы можете себе представить ситуацию, когда кто-нибудь спросил бы на Stackoverflow что-то типа «Why new C++ standard is beter?» и на него всей толпой накинулись за пропущенную букву? Там как-то понимают, что английский не всем родной (хотя это официальный язык сайта), а вот на Хабре в упор отказываются верить, что русский тоже может быть родным не каждому.
            • +1
              Дело не в том, что русский не является родным для Psionic, даже не в том, во всяком случае для меня, что он написал «лутше». А в том, что человек не признает ошибок… Ошибки в речи, даже в родной, не говоря уж о тех, для кого русский — второй/третий язык — это нормально, не нормально, когда они (ошибки) не признаются со ссылкой на то, что «Хабра не филологический ресурс», «мы не в школе», «мы не на диктанте», «у нас демократия, поэтому я волен писать так, как посчитаю нужным»
              Если бы Psionic сказал, что, мол, да, ошибся, я бы и слова не сказал.
              • 0
                Ну ошибался я ошибался — меня бы на плац да растреллять перед строем. А потом растрелляное тело приколотить к столбу чтоб каждый плюнул. Почему нужно давать синтаксическую оценку моему комментарию (я ж вроде своими кривыми ручёнками больмень понятно накалякал), а не задатся вопросом как мне реально поможет новый стандарт, почему меня мой бывший лид готов порвать за нетот свн клиент, за не там поставленый пробел, за то что не использую его любимый файловый манагер — ну да это конечно все проблемы на проекте решит и багобаза станет как девственица, а потоки станут упралять друг другом без помощи глобальных переменных, почему наши политики задаются по примеру РФовских вопросами об том надоли иностранцам усиновлять детей из Украины, мол сирот у нас много, а всем наплевать что «сироты» часто имеют синячащих без просыха биологических родителей и хотьбы кто из этих интелектуалов задался вопросм чтож у нас семьи то спиваются. Этим людям нужен психиатр, или мне нужен психиатр или хер его.
                • +1
                  Гм! Вам просто указали на ошибку, могли бы и не указывать, а могли и на другие указать… Указали и указали, запомнили, на ус намотали и в дальнейшем постарались не совершать… делов-то…

                  По теме, что вы хотите увидеть в стандарте, что позволило бы сделать ваши программы лучше?
                  Я не очень активно использую с++, для меня новый стандарт в общем-то сводится к синтаксическому сахару в виде «auto» и т.п. Так что, какой-то киллер-фичи я как и вы не наблюдаю…
                  • 0
                    По своему опыту я бы хотел увидеть:
                    1) Циклические операции битового сдвига.
                    2) Некоторые изменения в логике стандартных операций битового сдвига — то что сейчас не соотвествует логике исполнения процессором, к примеру 8 битная и 16 битная и 32 битная ложатся в один регистр всегда и к целому регистру уже применяется комманда, нужно чтоб если размер меньше регистра — команда вызывалась к половине/четверти регистра.
                    3) хочется чтоб файлы срр можно было одновременно использовть для обьявления (не вместо хидеров, а вместе сними) — тоесть если ради копеечного класса лень городить два файла, всю информацию об структре/обьявлениях компилятор мог извлеч из другого срр-файла, но при этом не включив реализацию и отделно скомпилировав этот файл.
                    4) Да стандартизируйте же прагмы наконец — удобно то как.
                    • 0
                      1) Зачем? Введение нового оператора — вопрос проблематичный. Необходимость данного оператора близка к нулевой (легко реализуется тремя операторами << | >>).
                      2) Честно не понял, что имеется в виду. Сделать дополнительно &? Процессор ведь не работает с половиной/четвертью регистра.
                      3) Близко к модулям в C++. В C++11 не вошло.
                      4) pragma для того и сделаны, чтобы ввести поведение специфичное для компиляторов. А вообще интересно, какие pragma интересуют?
                      • 0
                        По второму пункту:

                        Угадайте с трех раз — какой тип возвращает сдвиг всегда? Это тип соотвествует размеру регистра — всегда, это проиходит изза того что команада процессора для сдвига (shl/shr в х86) всегда вызывается для целого регистра, почему для целого — потому что так собирает компилятор, в ассемблерном трансляторе нам ничего не мешаетвызвать эти комманди и для eax/ax/al. Если бы компилятор — подганял размер переменной по размеру / дольки регистра, то оператор
                        • 0
                          Понял. Только не понял при чём тут регистры. Регистры — это уже заботы компилятора, а не стандарта. А стандарт оговаривает, что результат операции над char, short и int будет int. Это справедливо не только для сдвигов. char+char=int.
    • 0
      1. auto. Может не сверхнеобходимо, но позволяет избежать ненужных typedef'ов, сократить код.
      2. decltype и новое объявление функций позволяют упростить шаблоны.
      3. лямбды — не нужно выносить отдельные маленькие функции, вроде компараторов, не теряется контекст при чтении программы.
      4. потоки, мьютексы и т.п. Да, boost::thread существует давно, как и куча других способов работы с потоками. Но стандарт — это позитивно, универсально. Аналогично, регулярные выражения, «умные» указатели, хеш-таблицы.
      5. r-value references, семантика переноса — ускорение при сохранении ООП стиля.
      6. extern template позволяют ускорить сборку проекта, завязанного на шаблоны.
      7. списки инициализации — упрощение инициализации сложных типов.
      8. шаблоны с переменным числом аргументов — даже если не используете явно, упрощает тот же boost.
      9. не столь значительные, но полезные штуки: инициализация полей класса, делегирование конструкторов, for(:), строковые константы новые.
      10. улучшения в плане строгости и контроля: constexpr, final, override

      Как по мне, вполне неплохой список.
  • –2
    Я 15 лет пишу на C++, и стараюсь всячески избегать указателей, тем более указателей на указатели, работы с new/delete, и совершенно не понимаю как пользоваться const. Я с грустью смотрю на & и *, и каждый раз открываю свои записульки чтобы понять, где ссылка, где указатель, где одно преобразуется в другое, а где происходит разыменовывание. Работая с массивами, особенно двумерными, никогда не знаю, правильно ли написал обращение к ячейке или копирование куска массива. Всегда имею директорию под рукой, чтобы там написать маленькую програмку и протестировать что я делаю. На это уходит время.

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

    С появлением C++11 стал понимать, что я уже ничего ничего не понимаю в плюсах.

    Для меня единственное важное усовершенствование в языке — это auto. Всё остальное — усложнение в такие дали, что непонятно кто сможет эти нововведения использовать.
    • +2
      Просто вы зря пишите на C++ переходите на Java или C#, там этих «ужасов» нет.

      p.s: пойду закошмарю окружающих, всё таки почти 7 летний стаж на С/C++, и опыт работы с железками, позволяет… вухахахахаха ]:->

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка