![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Я писал юзер-интерфейсы еще на MFC, я писал их на Qt. Я освоил андроид (хотя лейауты меня там немножко напрягали), и даже недавно с полпинка написал все что нужно было на React JS. Но вот блин iOS с Xcode - это какой-то адский ад. Я не говорю про Objective-C, его я тоже достаточно давно не люблю но умею, однако вот как можно было так запутать связывание кнопки во вьюхе с ее хендлером, так что я потратив два часа still don't have the foggiest, я не понимаю. Надо книжки читать, похоже, потому что официальная документация больше смахивает на doxygen какой-то.
Забавная ерунда с ескейпингом
Apr. 16th, 2015 06:05 pmJSON формат не требует эскейпить значек градусов (°). И в принципе при генерации JSON'а с этим значком никаких проблем не возникает, валидацию он проходит, жабаскрипт его правильно распарсивает. Однако если такой JSON послать через WebSocket, то случится бида – браузер посчитает пришедшее невалидным UTF-8.
Я вот не понимаю
Nov. 24th, 2014 12:06 pmАнонсирован Gngr, новый web-браузер, ориентированный на обеспечение приватности
http://www.opennet.ru/opennews/art.shtml?num=41112
В комментах браузер критикуют только за то, что он написан на Жаве. Причем, цепляются к "избежать проблем с безопасностью, свойственных продуктам на С/C++".
Прямой доступ к памяти из языка – это в самом деле проблема с безопасностью. Ей можно пренебречь в более-менее монолитных проектах, требующих максимальной производительности. В случае оупенсорса, как показала практика, наличие сотен комиттеров и простота получения UB для языка напрямую влияют на количество уязвимостей. Можно тот же OpenSSL вспомнить. Да, чисто теоретически грамотный программист не допустит "плохого кода", а даже если допустит - коммит не пройдет ревью, но в реальной жизни все сложнее. Программист не совсем понимает чужой код, ревьюер смотрит на код в отрыве от контекста – ошибки пролезают в продакшн. В джаве это приведет к экзепшну, в C/C++ – к неопределенному поведению. Я не говорю что виртуальная машина жавы без изъянов, но она берет на себя функцию детекта ошибок программиста в рантайме, и это – дополнительный уровень защиты.
http://www.opennet.ru/opennews/art.shtml?num=41112
В комментах браузер критикуют только за то, что он написан на Жаве. Причем, цепляются к "избежать проблем с безопасностью, свойственных продуктам на С/C++".
Прямой доступ к памяти из языка – это в самом деле проблема с безопасностью. Ей можно пренебречь в более-менее монолитных проектах, требующих максимальной производительности. В случае оупенсорса, как показала практика, наличие сотен комиттеров и простота получения UB для языка напрямую влияют на количество уязвимостей. Можно тот же OpenSSL вспомнить. Да, чисто теоретически грамотный программист не допустит "плохого кода", а даже если допустит - коммит не пройдет ревью, но в реальной жизни все сложнее. Программист не совсем понимает чужой код, ревьюер смотрит на код в отрыве от контекста – ошибки пролезают в продакшн. В джаве это приведет к экзепшну, в C/C++ – к неопределенному поведению. Я не говорю что виртуальная машина жавы без изъянов, но она берет на себя функцию детекта ошибок программиста в рантайме, и это – дополнительный уровень защиты.
.NET goes Linux
Nov. 14th, 2014 07:57 amНет, я не имею в виду всякие поделки типа mono.
http://news.microsoft.com/2014/11/12/microsoft-takes-net-open-source-and-cross-platform-adds-new-development-capabilities-with-visual-studio-2015-net-2015-and-visual-studio-online/
Майкрософт решила официально поддерживать линукс и OS X.
Это замечательно, я считаю. Синтаксис шарпа очень и очень хорош (хотя я продолжаю в основном писать на плюсах, так как при всех минусах кроссплатформенность наилучшая получается). Если оно без потерь производительности будет на линуксах работать, дотнет отъест солидный кусок у жавы и даже вероятно рельсов.
http://news.microsoft.com/2014/11/12/microsoft-takes-net-open-source-and-cross-platform-adds-new-development-capabilities-with-visual-studio-2015-net-2015-and-visual-studio-online/
Майкрософт решила официально поддерживать линукс и OS X.
Это замечательно, я считаю. Синтаксис шарпа очень и очень хорош (хотя я продолжаю в основном писать на плюсах, так как при всех минусах кроссплатформенность наилучшая получается). Если оно без потерь производительности будет на линуксах работать, дотнет отъест солидный кусок у жавы и даже вероятно рельсов.
Elliptic curve Diffie–Hellman
Nov. 4th, 2014 01:35 amНаткнулся тут. Разновидность Диффи-Хельмана, модифицированная для получения в итоге симметричного ключа. Стороны генерят как обычно пары прайвит/паблик ключей, обмениваются открытыми. Затем обе стороны на основе своего прайвита и чужого паблика получают одинаковый(!) набор данных. Который можно потом использовать как ключ для симметричного и оптимизированного со всех сторон AES например.
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
А на макоси вполне можно кодить
Nov. 1st, 2014 02:32 amЯ тут неожиданно из-за поддержки блютуз наушников перелез с винды на макось, что пробовал раньше, но как-то не особо задерживался (рекордом вроде неделя была). После того как я винду обновил до 8.1 – понял что один хрен теперь, и вот три недели что ли уже на макоси сижу.
Они пофиксили мэверик, хитрыми манипуляциями с консолью удалось сделать мгновенное появление дока (меня ранее напрягало его ленивое выезжание с паузой). Я его сдвинул вбок и он не ест площадь экрана, так же как на винде. Шрифты для не-ретина экранов правда испортили, но на ретине все окей, а для остальных есть Йосемити.
Еще маководы любят всякие iTerm'ы вместо терминала, это полная бурда. Я поставил нормальный "виндовый" SecureCRT, где искаропки почти все настроено как надо и все нужные комбинации клавиш работают. Удобнейшая штука + там же SFTP клиент (SecureFX).
Основная засада была с C++. Не придумали еще отладчика более удобного чем Visual Studio. К QtCreator/XCode у меня была основная претензия что нельзя смотреть внутрь STL контейнеров. Открываешь контейнер - а там мешанина поинтеров. Это тоже пофиксили, правда только в XCode. QtCreator юзает какие-то пайтоновские биндинги и они глючат с C++11. Клэнг, на который XCode перешел год что ли назад, теперь обладает практически всеми теми же рантайм чеками, что есть в студии. Т.е. не оказываешься в ситуации характерной для гцц - когда все давно уже поломалось, но заметно стало только сейчас. И компиляет раза в два-три шустрее. Короче говоря, вполне себе годно получилось. Эппл правда упорно пытается саботировать визуальную часть продолжая линию iOS7, но в остальном меня прогресс радует.
Чего реально не хватает, так это какого-нибудь редактора текста с функцией Find in Files. В студии очень удобно сделано - нажал Ctrl + Shift + F и пробежался по всем файлам в директории или проекте, в экскоде есть Find Selected Text in Project, но там как-то по-дурацки скоупы настраиваются и путь к директории надо руками прописывать. В фаиндере проблема "я сюда попал и не знаю как выйте выше" решается включением "breadcrumbs" снизу окна, но полный путь скопировать не получается.
Они пофиксили мэверик, хитрыми манипуляциями с консолью удалось сделать мгновенное появление дока (меня ранее напрягало его ленивое выезжание с паузой). Я его сдвинул вбок и он не ест площадь экрана, так же как на винде. Шрифты для не-ретина экранов правда испортили, но на ретине все окей, а для остальных есть Йосемити.
Еще маководы любят всякие iTerm'ы вместо терминала, это полная бурда. Я поставил нормальный "виндовый" SecureCRT, где искаропки почти все настроено как надо и все нужные комбинации клавиш работают. Удобнейшая штука + там же SFTP клиент (SecureFX).
Основная засада была с C++. Не придумали еще отладчика более удобного чем Visual Studio. К QtCreator/XCode у меня была основная претензия что нельзя смотреть внутрь STL контейнеров. Открываешь контейнер - а там мешанина поинтеров. Это тоже пофиксили, правда только в XCode. QtCreator юзает какие-то пайтоновские биндинги и они глючат с C++11. Клэнг, на который XCode перешел год что ли назад, теперь обладает практически всеми теми же рантайм чеками, что есть в студии. Т.е. не оказываешься в ситуации характерной для гцц - когда все давно уже поломалось, но заметно стало только сейчас. И компиляет раза в два-три шустрее. Короче говоря, вполне себе годно получилось. Эппл правда упорно пытается саботировать визуальную часть продолжая линию iOS7, но в остальном меня прогресс радует.
Чего реально не хватает, так это какого-нибудь редактора текста с функцией Find in Files. В студии очень удобно сделано - нажал Ctrl + Shift + F и пробежался по всем файлам в директории или проекте, в экскоде есть Find Selected Text in Project, но там как-то по-дурацки скоупы настраиваются и путь к директории надо руками прописывать. В фаиндере проблема "я сюда попал и не знаю как выйте выше" решается включением "breadcrumbs" снизу окна, но полный путь скопировать не получается.
Оцпенсорц strikes back
Oct. 31st, 2014 08:17 pmКак оказалось, временные зоны вшиваются в пакетик libicu. Соответственно весь софт, зависящий от этой библиотечки все еще живет по Медведевскому времени. Причем вообще непонятно каким вменяемым образом можно читать зоны из системной tzdata (ну, кроме zdump, нужен программный способ).
Igor Pavlov конечно гениальный программист, его архиватор на данный момент обеспечивает наилучшее качество сжатия и защиту архивов паролем. Но плюсовый код в 7zip SDK меня просто убивает. "A bit of a mess", как про него в интернете говорят, doesn't even begin to describe it.
Самое странное, что сами кодеры/декодеры имеют вполне явно выделенный понятный интерфейс и, скажем, сжать файл в lzma никакой проблемы не составляет. Однако из сериализации-десериализации 7zip формата сделано какое-то вуду, плотно повязанное на фичи консольного и гуевого клиентов, с функциями по 15 аргументов. В итоге создается впечатление, что проще свой формат архивов реализовать, чем в этом всем разбираться. Народ, тем не менее, пытается как-то с этим делом разобраться, пишет свои обертки типа lib7zip (только декодирование), поддержка 7zip была добавлена в libarchive (без шифрования), но полноценной потоковой обертки так никто и не сделал.
UPD: Таки есть более упрощенный вариант реализации! Запрятанный в Client7z.cpp. Если внимательно его почитать, практически все становится в 10 раз проще чем родной актуальный клиент. Где б еще в документации про него написали, он ведь даже не компилируется в стандартном варианте.
Самое странное, что сами кодеры/декодеры имеют вполне явно выделенный понятный интерфейс и, скажем, сжать файл в lzma никакой проблемы не составляет. Однако из сериализации-десериализации 7zip формата сделано какое-то вуду, плотно повязанное на фичи консольного и гуевого клиентов, с функциями по 15 аргументов. В итоге создается впечатление, что проще свой формат архивов реализовать, чем в этом всем разбираться. Народ, тем не менее, пытается как-то с этим делом разобраться, пишет свои обертки типа lib7zip (только декодирование), поддержка 7zip была добавлена в libarchive (без шифрования), но полноценной потоковой обертки так никто и не сделал.
UPD: Таки есть более упрощенный вариант реализации! Запрятанный в Client7z.cpp. Если внимательно его почитать, практически все становится в 10 раз проще чем родной актуальный клиент. Где б еще в документации про него написали, он ведь даже не компилируется в стандартном варианте.
Раньше при замене типа контейнера с листа, например, на map – приходилось менять весь клиентский код, так как менялась семантика использования итераторов (вместо просто значения - пара ключ-значение).
В C++11 можно сделать вот так:
Ссылка на тему: http://stackoverflow.com/questions/21408251/how-to-declare-boost-range-adaptor-e-g-map-values
В C++11 можно сделать вот так:
auto list() const -> decltype( my_map | boost::adaptors::map_values ) {
return my_map | boost::adaptors::map_values;
}И отдать "наверх" тип, который позволяет итерировать только по значениям этого map (я понимаю что рубисты/дотнетчики на этом месте покрутят у виска, у них эти возможности давно уже есть, но для С++ это типа big deal).Ссылка на тему: http://stackoverflow.com/questions/21408251/how-to-declare-boost-range-adaptor-e-g-map-values
Смотрел тут OneDrive REST API
Oct. 24th, 2014 10:00 pmКому-то в Майкрософт упорно хочется чтобы люди не имели другой возможности авторизоваться кроме как онлайн. Причем их десктопный клиент вполне нормально авторизуется только по логину-паролю.
А так там зоопарк какой-то, авторизационный ключ, авторизационный токен, эксес токен, рефреш токен. Причем, два последних меняются каждый час, а получить первый можно только HTTP колбеком-редиректом. Фактически, чтобы свое приложение на этом выстроить, надо или через сторонний/свой веб-сайт коллбек-ключи пропускать (что меня как пользователя напрягло бы), или встраивать браузер в приложение. И авторизовать юзера каждый раз когда он компьютер включает.
Наводит на мысли, что если бы Амазон упростил бы регистрацию своего инстанса S3, то принимая во внимание количество существующих утилит синхронизации и цен, OneDrive быстро бы пошел лесом.
А так там зоопарк какой-то, авторизационный ключ, авторизационный токен, эксес токен, рефреш токен. Причем, два последних меняются каждый час, а получить первый можно только HTTP колбеком-редиректом. Фактически, чтобы свое приложение на этом выстроить, надо или через сторонний/свой веб-сайт коллбек-ключи пропускать (что меня как пользователя напрягло бы), или встраивать браузер в приложение. И авторизовать юзера каждый раз когда он компьютер включает.
Наводит на мысли, что если бы Амазон упростил бы регистрацию своего инстанса S3, то принимая во внимание количество существующих утилит синхронизации и цен, OneDrive быстро бы пошел лесом.
Скотт Мейерс жжот
Jun. 23rd, 2014 02:42 pm-- How many people that went writing their unit-tests are testing with containers of more than 4 billion elements?
http://vimeo.com/97318797
(еще на самом деле забавно наблюдать как чел типичного nerd-weirdo вида научился вполне неплохо публично говорить, не конкретно в этом видео, а вообще)
http://vimeo.com/97318797
(еще на самом деле забавно наблюдать как чел типичного nerd-weirdo вида научился вполне неплохо публично говорить, не конкретно в этом видео, а вообще)
Занимательный чарт
Jun. 17th, 2014 02:18 am
Я только так и не понял откуда они данные берут. Я тут интереса ради периодически на dice.com посматриваю, так там другие цифры получаются:
Java - 16k вакансий
С++ - 15к
C# - 8k
Python - 5k
Ruby + Rails - 4k
Objective-C + iOS - 3k
Windows is officially dead. Я давно удивлялся почему не сделана такая вроде бы очевидная фича как ответ на звонок с другого девайса (скажем я с ноутбуком на кухне, телефон в комнате) и синхронизация SMS.
Они это сделали (зарелизят правда только осенью), вместе с кучкой других фич. Оно конечно для безопасности не очень хорошо, так как iCloud теперь интегрировали вообще во все, но NSA и юзерам так удобнее :)
Из смешного - зарелизили новый язык на смену Objective-C. Так и представили - новый язык без груза C. Выглядит как смесь Objective-C и руби, хотя я при виде "let" почему-то бейсик вспомнил. Но оно все еще очень зеленое, можно особо не присматриваться. Наверняка почувствовали угрозу со стороны C# и моно (да и девелоперов наверняка давно уже тошнит от obj-c), решили подсуетиться.
Скачал новый XCode пока смотрел презентацию - nah, отлаживать плюсы нормально так и не научились, даже std::map в нормальном виде не посмотреть (хотя интеллисенс и автокомплит работает гораздо интереснее).
Они это сделали (зарелизят правда только осенью), вместе с кучкой других фич. Оно конечно для безопасности не очень хорошо, так как iCloud теперь интегрировали вообще во все, но NSA и юзерам так удобнее :)
Из смешного - зарелизили новый язык на смену Objective-C. Так и представили - новый язык без груза C. Выглядит как смесь Objective-C и руби, хотя я при виде "let" почему-то бейсик вспомнил. Но оно все еще очень зеленое, можно особо не присматриваться. Наверняка почувствовали угрозу со стороны C# и моно (да и девелоперов наверняка давно уже тошнит от obj-c), решили подсуетиться.
Скачал новый XCode пока смотрел презентацию - nah, отлаживать плюсы нормально так и не научились, даже std::map в нормальном виде не посмотреть (хотя интеллисенс и автокомплит работает гораздо интереснее).
Тут коллеги петицию выдвигают
Jun. 3rd, 2014 01:09 amНе нравится им что у меня в C++ коде все в хедерах, без cpp. Причем, жалуется только почему-то народ на gcc и clang'е.
Я не знаю насколько распространена эта практика, но мне всегда казалось странным разделать заголовки и имплементацию, поэтому я пишу все в хедерах. Типа как в Java, C#, да и вообще везде практически, кроме чистых C и Objective-C.
Началось это достаточно давно, когда я был в конторе чуть ли не единственным C++ программером, поэтому делал как мне удобно.
Сейчас кодовая база подросла, люди подтянулись, жалуются на длинные компиляции и долгую пересборку после единственного изменения.
Мое мнение, что если в проекте один файл main.cpp, то и компиляться будет шустро. Все равно там бустовых темплейтов в 10 раз больше чем собственно нашего кода, а 20-30-40-100 раз их компилять заново на каждом cpp это глупо как-то. Нехай все в одном компиляется.
Но посмотрим, надо разбить существующий код утилиткой какой на .h и .cpp, и замерить время компиляции и перекомпиляции. Вдруг в самом деле это я людей плохому учу.
Хотя, на самом деле, попытки ускорить компиляцию через cpp файлы это просто другая банка червей. Начинаются забавы с форвард-декларейшнами, пимплами и прочей специфичной плюсам ерундой, про которую другие языки и не знают даже.
Я не знаю насколько распространена эта практика, но мне всегда казалось странным разделать заголовки и имплементацию, поэтому я пишу все в хедерах. Типа как в Java, C#, да и вообще везде практически, кроме чистых C и Objective-C.
Началось это достаточно давно, когда я был в конторе чуть ли не единственным C++ программером, поэтому делал как мне удобно.
Сейчас кодовая база подросла, люди подтянулись, жалуются на длинные компиляции и долгую пересборку после единственного изменения.
Мое мнение, что если в проекте один файл main.cpp, то и компиляться будет шустро. Все равно там бустовых темплейтов в 10 раз больше чем собственно нашего кода, а 20-30-40-100 раз их компилять заново на каждом cpp это глупо как-то. Нехай все в одном компиляется.
Но посмотрим, надо разбить существующий код утилиткой какой на .h и .cpp, и замерить время компиляции и перекомпиляции. Вдруг в самом деле это я людей плохому учу.
Хотя, на самом деле, попытки ускорить компиляцию через cpp файлы это просто другая банка червей. Начинаются забавы с форвард-декларейшнами, пимплами и прочей специфичной плюсам ерундой, про которую другие языки и не знают даже.
Herb Sutter asks all the right questions:
“Why can’t I share C++ libraries even between my own internal teams without using the identical compiler and switch settings?” “Why are operating system APIs written in unsafe C, instead of C++?” “Why can’t I use std::string in a public shared library interface; it’s the C++ string, isn’t it?!”
http://herbsutter.com/2014/05/21/cppcon-my-proposed-talks-part-2/
Я вот чего не понимаю, эти ребята со Страуструпом во главе реально не понимают, что им просто нужен новый язык? Синтаксис плюсов был волосат еще до C++11, а теперь, после того как они туда напихали лямбд, райт вэлью референсов и прочего прочего, любой новичок 10 раз подумает зачем ему изучать весь этот зоопарк, а старички скажут что-то вроде "20 лет без этого жили и дальше проживем". Нереально запихнуть в язык все модные фишки и оставить синтаксис вменяемым. Люди не должны думать "о, замечательно, тут будет лямбда, только я посмотрю сколько закорючек и амперсандов мне нужно чтобы написать ее". Нельзя делать синтаксис сложнее чем у ближайших конкурентов. Я не спорю, что в C++11 много полезных и нужных новшеств, а в C++14 их еще лучше причешут, но как-то оно все не туда идет.
Логичнее было бы сделать новый язык, взять синтаксис тех же лямбд из жаваскрипта или си-шарпа, на уровне интерфейсов/компилятора сделать его легко стыкуемым с С++ и жить себе припеваючи! Хочешь гэрбэдж коллектор, лямбды, 'everything is an object' - юзай новый язык. Хочешь избавиться от оверхеда удобства быстрой разработки - пиши код на С++ и включай его из нового языка, компилятор позаботится об эффективности вставок. Это было бы офигенно удобное комбо.
А так - синтаксис расширяется, кода становится больше, а не меньше (что неправильно). Microsoft Compiler например научился нормально C++11 поддерживать только с 12-й версии, которая в октябре 2013 года вышла. Разработчики рвутся использовать новые фичи, но каждый компилятор реализует свой подсет новых фич, бустовые заимствования в STL делают бардак из состыковки старого кода и старого.
Я уже открыто коллегам говорю - не пытайтесь связать свое будущее только с С++. Несмотря на быстроту, портабельность и кучу легаси кода, язык упорно загоняют в какую-то жопу. Новичкам проще изучить жабу или си-шарп и уже через пару лет считаться неплохими спецами. В С++ человек лет только через пять перестает писать говнокод и может считаться вменяемым. В ситуации, когда работодатели уже не могут найти нормальных С++ программистов, а значит новые проекты будут начинать на чем-то еще, язык постепенно загнется (лет так через 10). И достаточно глупо надеяться что при этом специалисты по С++ сильно поднимутся в цене. Некоторый спрос будет, да, но случится как с перлом - старички забьют все вакантные позиции, а новых мест создаваться просто не будет.
Если на уровне "Cи с классами" язык был прост в изучении и сравнительно удобнее чистого Си, то на уровне "Си++ с блекджеком и прочим" - not so much. Учитывая вытеснение языка на embedded девайсы и критичные к математической производительности движки - плюсы плюсов становятся все менее очевидными.
“Why can’t I share C++ libraries even between my own internal teams without using the identical compiler and switch settings?” “Why are operating system APIs written in unsafe C, instead of C++?” “Why can’t I use std::string in a public shared library interface; it’s the C++ string, isn’t it?!”
http://herbsutter.com/2014/05/21/cppcon-my-proposed-talks-part-2/
Я вот чего не понимаю, эти ребята со Страуструпом во главе реально не понимают, что им просто нужен новый язык? Синтаксис плюсов был волосат еще до C++11, а теперь, после того как они туда напихали лямбд, райт вэлью референсов и прочего прочего, любой новичок 10 раз подумает зачем ему изучать весь этот зоопарк, а старички скажут что-то вроде "20 лет без этого жили и дальше проживем". Нереально запихнуть в язык все модные фишки и оставить синтаксис вменяемым. Люди не должны думать "о, замечательно, тут будет лямбда, только я посмотрю сколько закорючек и амперсандов мне нужно чтобы написать ее". Нельзя делать синтаксис сложнее чем у ближайших конкурентов. Я не спорю, что в C++11 много полезных и нужных новшеств, а в C++14 их еще лучше причешут, но как-то оно все не туда идет.
Логичнее было бы сделать новый язык, взять синтаксис тех же лямбд из жаваскрипта или си-шарпа, на уровне интерфейсов/компилятора сделать его легко стыкуемым с С++ и жить себе припеваючи! Хочешь гэрбэдж коллектор, лямбды, 'everything is an object' - юзай новый язык. Хочешь избавиться от оверхеда удобства быстрой разработки - пиши код на С++ и включай его из нового языка, компилятор позаботится об эффективности вставок. Это было бы офигенно удобное комбо.
А так - синтаксис расширяется, кода становится больше, а не меньше (что неправильно). Microsoft Compiler например научился нормально C++11 поддерживать только с 12-й версии, которая в октябре 2013 года вышла. Разработчики рвутся использовать новые фичи, но каждый компилятор реализует свой подсет новых фич, бустовые заимствования в STL делают бардак из состыковки старого кода и старого.
Я уже открыто коллегам говорю - не пытайтесь связать свое будущее только с С++. Несмотря на быстроту, портабельность и кучу легаси кода, язык упорно загоняют в какую-то жопу. Новичкам проще изучить жабу или си-шарп и уже через пару лет считаться неплохими спецами. В С++ человек лет только через пять перестает писать говнокод и может считаться вменяемым. В ситуации, когда работодатели уже не могут найти нормальных С++ программистов, а значит новые проекты будут начинать на чем-то еще, язык постепенно загнется (лет так через 10). И достаточно глупо надеяться что при этом специалисты по С++ сильно поднимутся в цене. Некоторый спрос будет, да, но случится как с перлом - старички забьют все вакантные позиции, а новых мест создаваться просто не будет.
Если на уровне "Cи с классами" язык был прост в изучении и сравнительно удобнее чистого Си, то на уровне "Си++ с блекджеком и прочим" - not so much. Учитывая вытеснение языка на embedded девайсы и критичные к математической производительности движки - плюсы плюсов становятся все менее очевидными.
