Comments 64
Надеюсь, c++14 не превратится в c++2x :)
Ещё одним событием, которое способствует развитию С++ и Qt случайно стали проблемы с уязвимостями в Java, которых недавно было найдено сразу несколько. Одним из важных факторов выбора Java раньше была его «безопасность», в сравнении с С++. Прошлый год показал, что столь уж явного и безоговорочного преимущества в безопасности эта платформа не имеет.
Были неоднократные проблемы с браузерным плагином, но тот логический вывод, который автор приводит выглядит весьма нелепым.
1. Проблемы были не только с браузерными плагинами.
2. Некоторые компании решили вообще поудалять рантайм Java со своих компьютеров. Им неизменно придётся выбирать программы, написанные на чём-то другом, что повышает рейтинг С++
Автор слегка категоричен (а может даже слегка злорадствует), но он частично прав.
2. Некоторые компании решили вообще поудалять рантайм Java со своих компьютеров. Им неизменно придётся выбирать программы, написанные на чём-то другом, что повышает рейтинг С++
Автор слегка категоричен (а может даже слегка злорадствует), но он частично прав.
Мне кажется, что автор прав относительно падения привлекательности Java, но ошибается в причинах. Уязвимости были только в браузерах, а в таком виде на Java уже никто не пишет. Намного более серьёзной проблемой является то, что как язык Java стагнирует уже очень давно. А в C++ как раз новый стандарт наделал положительного пиара. Тогда как в Java 8 (будущий релиз) вводят ограниченный type inference (diamond operator), в C++ уже есть нормальный auto.
Scala немного помогает Java миру, в последнем релизе вот шаблоны добавили. Но это слишком «академический» язык, он вряд ли добьётся массовости и изменит мир.
Поэтому к C++ возвращается утерянный было образ «cool kid», потом и растёт интерес к нему.
Scala немного помогает Java миру, в последнем релизе вот шаблоны добавили. Но это слишком «академический» язык, он вряд ли добьётся массовости и изменит мир.
Поэтому к C++ возвращается утерянный было образ «cool kid», потом и растёт интерес к нему.
В Scala и Java не шаблоны, а параметризованные типы. Это разные вещи.
Растолкуйте разницу или тыкнете носом где почитать пожалуйста. Первые ссылки гугла не помогли.
Грубо говоря, темплеты это кодогенерация. При инстансиировании шаблона, код просто генерится. То что при инстасиировании темплетов не будет ошибок нам не гарантируется. Параметрические типы это полноценные типы. Почитать можно например здесь:
— stackoverflow.com/questions/31693/what-are-the-differences-between-generics-in-c-sharp-and-java-and-templates-i
— msdn.microsoft.com/en-us/library/c6cyy67b.aspx
— blogs.msdn.com/b/csharpfaq/archive/2004/03/12/how-do-c-generics-compare-to-c-templates.aspx
— stackoverflow.com/questions/31693/what-are-the-differences-between-generics-in-c-sharp-and-java-and-templates-i
— msdn.microsoft.com/en-us/library/c6cyy67b.aspx
— blogs.msdn.com/b/csharpfaq/archive/2004/03/12/how-do-c-generics-compare-to-c-templates.aspx
Я же написал «в последнем релизе». Читайте: docs.scala-lang.org/overviews/macros/overview.html
полноценной его поддержке в Visual Studio 2012
Хорошая шутка ;)
Вы зря не смотрите выступления Херба, он там много всякого рассказывал, и о студии 2012 и о плане апдейтов компилятора отвязанном от общих апдейтов студии.
Выступления, планы и объективная реальность — всё-таки немного разные вещи.
Да в vs2012 даже банальный
При всей моей любви к vs(основная ide, в которой работаю), я уже давно привык, что от стандартам она частенько не соответствует. И пока не верю, что 2012я будет в этом плане отличаться от предыдущих. Очень хотелось бы оказаться неправым в этот раз…
Да в vs2012 даже банальный
std::map<std::string, int> m = { { "a", 1 }, { "b", 2 } }; не компилируется. Вы на количество No и Partial вот здесь смотрели?При всей моей любви к vs(основная ide, в которой работаю), я уже давно привык, что от стандартам она частенько не соответствует. И пока не верю, что 2012я будет в этом плане отличаться от предыдущих. Очень хотелось бы оказаться неправым в этот раз…
Перевести бы их на clang всех.
moadib, приведенный Вами код не компилируется в силу того, что на момент выхода November CTP Stephen не успел обновить STL. Когда CTP превратиться в релиз(или RC) то Вы обязательно скомпилируете этот код. Ждать следующей стадии в CTP осталось не долго, я полагаю.
И Вам не зря указали на выступления Герба; на данный момент Microsoft действительно заинтересовано в скорейшей имплементации стандарта в своём компиляторе. Поэтому есть все основания полагать, что в 2013 году мы увидим полную поддержку стандарта в студии(тем более, что из сложных фич не реализовано только constexpr, насколько я помню)
И Вам не зря указали на выступления Герба; на данный момент Microsoft действительно заинтересовано в скорейшей имплементации стандарта в своём компиляторе. Поэтому есть все основания полагать, что в 2013 году мы увидим полную поддержку стандарта в студии(тем более, что из сложных фич не реализовано только constexpr, насколько я помню)
Ну может они ещё сахарку подкинут помимо auto, было б очень неплохо.
Я бы больше был бы рад, если бы метаинформацию для рефлексии добавили. Чтобы можно было сигналы, слоты и свойства в Qt делать без использования moc'а.
UFO just landed and posted this here
Более того, там столько всего менять придётся — ужас. Я на 99% уверен, что модули в С++14 не войдут. Очень уж масштабное изменение.
UFO just landed and posted this here
Вот никогда не понимал этого странного желания «ничего не менять», лишь бы не сломать «обратную совместимость». Кто не хочет — пускай юзает старые компиляторы! А нормальные программисты захотят использовать новые и с удовольствием внесут изменения в свой код. А уж модули-то в первую очередь нужно вводить, дурацкую систему инклудов надо было выкинуть еще лет 20 назад.
Да конечно модули — это классно, а инклюды надо было 20 лет как выкинуть. Но сегодня изрядная часть программирования на С++ — поддержка старых проектов. Нового не так уж много стартует на плюсах. И вот для этих старых проектов будет тяжело модули присобачить.
Ну если поддержка старых проектов — то я же предлагаю не переходить на новые компиляторы, «поддержка» — это в лучшем случае исправление ошибок. В крайнем случае, если будут обнаружены ошибки в старом компиляторе, разработчики компиляторов могут выпустить исправленную версию компилятора для старого С++. Но такие случаи крайне редки.
А те, кто активно развивает проекты, добавляет новую функциональность — перейдут. Я бы с удовольствием перешел бы на модули, если бы они были:) И на рефлексию перешел бы, и на нормальные синтаксические макросы вместо адского «метапрограммирования на шаблонах», и на много чего еще.
А те, кто активно развивает проекты, добавляет новую функциональность — перейдут. Я бы с удовольствием перешел бы на модули, если бы они были:) И на рефлексию перешел бы, и на нормальные синтаксические макросы вместо адского «метапрограммирования на шаблонах», и на много чего еще.
Такие как вы и не начинают. А дайте нам то поиграться с чем-то новым. Тем более, что в обозримом будущем пока не видна полноценная замена тройке C++/C/ObjectiveC.
А чего-это вы в меня пальцем тыкаете? Я за последний год минимум несколько проектов начал на плюсах и статей по ним на Хабре написал немало. Другое дело, что у меня на то были причины, а у всё большего количества нынешних проектов (веб, андроид, айос — тренды) этих причин нет.
А на чем тогда вы предлагаете писать кроссплатформенные библиотеки?
В 90% случаев я предлагаю их не писать, а брать имеющиеся, которых выше крыши. В оставшихся 10% это может быть С, С++ или JAVA (это смотря какие платформы в каждом конкретном случае входят в понятие «кроссплатформенность»).
Я не пойму вы отрицаете тот факт, что нынче стартует больше проектов на управляемых\скриптовых языках, чем на С++?
Я не пойму вы отрицаете тот факт, что нынче стартует больше проектов на управляемых\скриптовых языках, чем на С++?
А чем модули могут повредить обратной совместимости? Вводим новую директиву (к примеру #include module «somefile»)
#include «vector»
#include module «MeshQuadro.cxx»
Чтото сорсвиевер хабрі не признает в спп треугольніх скобок.
#include «vector»
#include module «MeshQuadro.cxx»
Чтото сорсвиевер хабрі не признает в спп треугольніх скобок.
Посмотрите что творится с проектами, менющами API или стандарт языка постоянно. Ими просто никто не пользуется. Для комерческих пользователей очень важно, чтобы была обратная совместимость. Рефакторить весь код при выпуск на новую версию это слишком дорого.
Статья слишком оптимистична. На самом деле будет так:
В следующем году начнется работа над новым стандартом — С++21. В апреле 2015 пройдет встреча комитета по стандартизации С++ в Бристоне (Великобритания) и мы уже сможем представить себе наброски будущего стандарта. В октябре 2018 пройдет встреча в Чикаго, где должен быть уже сформирован более или менее чёткий черновик, который в конце 2021-го станет новым ISO-стандартом.
Так приятно слушать хорошее про любимый язык, особенно от пользователей хабра
Начали за здравие (С++14), а закончили за упокой (Qt). То ли автор забыл, что он собирался рассказать про С++14, то ли выделил это целым абзацем просто по невнимательности.
Java безопасна не в том смысле, что нет секьюрити дыр, а в том, что, обращение по непоянтному указателю, или за границы массива приводит не к порче памяти а к тому что просто вылетит ошибка времени выполнения.
Которая точно также приведет к краху приложения. Единственная разница в том, что в си и плюсах при обращении к непонятному указателю таки может «повезти», что таки приведет к появлению странной ошибки или вовсе гейзенбага.
Это исключение можно поймать, и память не поломается. Так вобщем-то обычно и делается. Разница имеено в том что не везет, и Гейзенбергов у нас не бывает. Программировать без этой радости намного удобнее и приятнее.
Если возникло такое искючение, то о штатном продолжении исполнения приложения не может быть и речи.
Я уже черти сколько ни разу в плюсах такой хрени не ловил.
Я уже черти сколько ни разу в плюсах такой хрени не ловил.
если вы используете высокоуровневые контейнеры, то да, но если вы где-то заиспользуете низкоуровневый код, то привет. и вам никто не будет гарантировать, что какой-нибудь junior девелопер не возомнит себя кул хацкером и не напишет низкоуровневый код, который раздолбает вам всю систему, а вы будете ловить Гейзенберга,
Никто не гарантирует, что юниор не разломает Java приложение. А вот штуки типа Геррита эту гарантию дают для любого проекта на любом ЯП. А если заапрувил коммит с кулхацкер извращениями, то ССЗБ.
ru.wikipedia.org/wiki/Gerrit
ru.wikipedia.org/wiki/Gerrit
В си/плюсах можно закорраптить вообще любую доступную приложению память, просто разыменовав dangling pointer. Проделайте-ка это в Java.
Apple также решила его использовать
LLVM/Clang тем, чем он сейчас является стал при непосредственном участии Apple
Ох щас мне и карму сольют, но скажу — что-то за время штудирования нового стандарта я не заметил ничего такого что позволило-бы сделать мои программы лутше, а вы?
[какой-то текст] лутше [какой-то текст]
Нет в русском языке такого слова! Вы переменные тоже называете
indeks, databeis, tvitter?О боже — в школе на мове, в университете на русском, по жизни на суржике! Хабра не филологический ресурс — атомного взрыва не случится от слова ЛУТШЕ!
Хабр — для грамотных людей.
Уважаемый Psionic указал на ту же проблему, с которой и я сталкиваюсь — если русский язык не родной, а к тому-же если в школе 11 лет говорил с учителями и одноклассниками на другом языке — выучить русский во взрослом возрасте на уровне жителя России, который занимался этим с детства — нереально. Понятно, что Хабр — для грамотных людей. Но вы можете себе представить ситуацию, когда кто-нибудь спросил бы на Stackoverflow что-то типа «Why new C++ standard is beter?» и на него всей толпой накинулись за пропущенную букву? Там как-то понимают, что английский не всем родной (хотя это официальный язык сайта), а вот на Хабре в упор отказываются верить, что русский тоже может быть родным не каждому.
Дело не в том, что русский не является родным для Psionic, даже не в том, во всяком случае для меня, что он написал «лутше». А в том, что человек не признает ошибок… Ошибки в речи, даже в родной, не говоря уж о тех, для кого русский — второй/третий язык — это нормально, не нормально, когда они (ошибки) не признаются со ссылкой на то, что «Хабра не филологический ресурс», «мы не в школе», «мы не на диктанте», «у нас демократия, поэтому я волен писать так, как посчитаю нужным»
Если бы Psionic сказал, что, мол, да, ошибся, я бы и слова не сказал.
Если бы Psionic сказал, что, мол, да, ошибся, я бы и слова не сказал.
Ну ошибался я ошибался — меня бы на плац да растреллять перед строем. А потом растрелляное тело приколотить к столбу чтоб каждый плюнул. Почему нужно давать синтаксическую оценку моему комментарию (я ж вроде своими кривыми ручёнками больмень понятно накалякал), а не задатся вопросом как мне реально поможет новый стандарт, почему меня мой бывший лид готов порвать за нетот свн клиент, за не там поставленый пробел, за то что не использую его любимый файловый манагер — ну да это конечно все проблемы на проекте решит и багобаза станет как девственица, а потоки станут упралять друг другом без помощи глобальных переменных, почему наши политики задаются по примеру РФовских вопросами об том надоли иностранцам усиновлять детей из Украины, мол сирот у нас много, а всем наплевать что «сироты» часто имеют синячащих без просыха биологических родителей и хотьбы кто из этих интелектуалов задался вопросм чтож у нас семьи то спиваются. Этим людям нужен психиатр, или мне нужен психиатр или хер его.
Гм! Вам просто указали на ошибку, могли бы и не указывать, а могли и на другие указать… Указали и указали, запомнили, на ус намотали и в дальнейшем постарались не совершать… делов-то…
По теме, что вы хотите увидеть в стандарте, что позволило бы сделать ваши программы лучше?
Я не очень активно использую с++, для меня новый стандарт в общем-то сводится к синтаксическому сахару в виде «auto» и т.п. Так что, какой-то киллер-фичи я как и вы не наблюдаю…
По теме, что вы хотите увидеть в стандарте, что позволило бы сделать ваши программы лучше?
Я не очень активно использую с++, для меня новый стандарт в общем-то сводится к синтаксическому сахару в виде «auto» и т.п. Так что, какой-то киллер-фичи я как и вы не наблюдаю…
По своему опыту я бы хотел увидеть:
1) Циклические операции битового сдвига.
2) Некоторые изменения в логике стандартных операций битового сдвига — то что сейчас не соотвествует логике исполнения процессором, к примеру 8 битная и 16 битная и 32 битная ложатся в один регистр всегда и к целому регистру уже применяется комманда, нужно чтоб если размер меньше регистра — команда вызывалась к половине/четверти регистра.
3) хочется чтоб файлы срр можно было одновременно использовть для обьявления (не вместо хидеров, а вместе сними) — тоесть если ради копеечного класса лень городить два файла, всю информацию об структре/обьявлениях компилятор мог извлеч из другого срр-файла, но при этом не включив реализацию и отделно скомпилировав этот файл.
4) Да стандартизируйте же прагмы наконец — удобно то как.
1) Циклические операции битового сдвига.
2) Некоторые изменения в логике стандартных операций битового сдвига — то что сейчас не соотвествует логике исполнения процессором, к примеру 8 битная и 16 битная и 32 битная ложатся в один регистр всегда и к целому регистру уже применяется комманда, нужно чтоб если размер меньше регистра — команда вызывалась к половине/четверти регистра.
3) хочется чтоб файлы срр можно было одновременно использовть для обьявления (не вместо хидеров, а вместе сними) — тоесть если ради копеечного класса лень городить два файла, всю информацию об структре/обьявлениях компилятор мог извлеч из другого срр-файла, но при этом не включив реализацию и отделно скомпилировав этот файл.
4) Да стандартизируйте же прагмы наконец — удобно то как.
1) Зачем? Введение нового оператора — вопрос проблематичный. Необходимость данного оператора близка к нулевой (легко реализуется тремя операторами << | >>).
2) Честно не понял, что имеется в виду. Сделать дополнительно &? Процессор ведь не работает с половиной/четвертью регистра.
3) Близко к модулям в C++. В C++11 не вошло.
4) pragma для того и сделаны, чтобы ввести поведение специфичное для компиляторов. А вообще интересно, какие pragma интересуют?
2) Честно не понял, что имеется в виду. Сделать дополнительно &? Процессор ведь не работает с половиной/четвертью регистра.
3) Близко к модулям в C++. В C++11 не вошло.
4) pragma для того и сделаны, чтобы ввести поведение специфичное для компиляторов. А вообще интересно, какие pragma интересуют?
По второму пункту:
Угадайте с трех раз — какой тип возвращает сдвиг всегда? Это тип соотвествует размеру регистра — всегда, это проиходит изза того что команада процессора для сдвига (shl/shr в х86) всегда вызывается для целого регистра, почему для целого — потому что так собирает компилятор, в ассемблерном трансляторе нам ничего не мешаетвызвать эти комманди и для eax/ax/al. Если бы компилятор — подганял размер переменной по размеру / дольки регистра, то оператор
Угадайте с трех раз — какой тип возвращает сдвиг всегда? Это тип соотвествует размеру регистра — всегда, это проиходит изза того что команада процессора для сдвига (shl/shr в х86) всегда вызывается для целого регистра, почему для целого — потому что так собирает компилятор, в ассемблерном трансляторе нам ничего не мешаетвызвать эти комманди и для eax/ax/al. Если бы компилятор — подганял размер переменной по размеру / дольки регистра, то оператор
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. decltype и новое объявление функций позволяют упростить шаблоны.
3. лямбды — не нужно выносить отдельные маленькие функции, вроде компараторов, не теряется контекст при чтении программы.
4. потоки, мьютексы и т.п. Да, boost::thread существует давно, как и куча других способов работы с потоками. Но стандарт — это позитивно, универсально. Аналогично, регулярные выражения, «умные» указатели, хеш-таблицы.
5. r-value references, семантика переноса — ускорение при сохранении ООП стиля.
6. extern template позволяют ускорить сборку проекта, завязанного на шаблоны.
7. списки инициализации — упрощение инициализации сложных типов.
8. шаблоны с переменным числом аргументов — даже если не используете явно, упрощает тот же boost.
9. не столь значительные, но полезные штуки: инициализация полей класса, делегирование конструкторов, for(:), строковые константы новые.
10. улучшения в плане строгости и контроля: constexpr, final, override
Как по мне, вполне неплохой список.
Я 15 лет пишу на C++, и стараюсь всячески избегать указателей, тем более указателей на указатели, работы с new/delete, и совершенно не понимаю как пользоваться const. Я с грустью смотрю на & и *, и каждый раз открываю свои записульки чтобы понять, где ссылка, где указатель, где одно преобразуется в другое, а где происходит разыменовывание. Работая с массивами, особенно двумерными, никогда не знаю, правильно ли написал обращение к ячейке или копирование куска массива. Всегда имею директорию под рукой, чтобы там написать маленькую програмку и протестировать что я делаю. На это уходит время.
А когда смотрю чужие опенсорчные проекты, так там вообще мрак, понять что имел в виду автор для меня не представляется возможным. Особенно радуют пионисты, которые пишут с использованием побочных эффектов, или заворачивают нечитабельные конструкции, которые нужно расшифровывать. И такие товарищи сплошь и рядом, такое впечатление, что идет соревнование кто напишет наиболее трудночитаемый код.
С появлением C++11 стал понимать, что я уже ничего ничего не понимаю в плюсах.
Для меня единственное важное усовершенствование в языке — это auto. Всё остальное — усложнение в такие дали, что непонятно кто сможет эти нововведения использовать.
А когда смотрю чужие опенсорчные проекты, так там вообще мрак, понять что имел в виду автор для меня не представляется возможным. Особенно радуют пионисты, которые пишут с использованием побочных эффектов, или заворачивают нечитабельные конструкции, которые нужно расшифровывать. И такие товарищи сплошь и рядом, такое впечатление, что идет соревнование кто напишет наиболее трудночитаемый код.
С появлением C++11 стал понимать, что я уже ничего ничего не понимаю в плюсах.
Для меня единственное важное усовершенствование в языке — это auto. Всё остальное — усложнение в такие дали, что непонятно кто сможет эти нововведения использовать.
Sign up to leave a comment.
C++ в 2013 году