Здравствуйте, lpd, Вы писали:
lpd>Странно звучат "все проверяется", и "гарантирует корректность кода", т.к. в реальных программах основную сложность составляют проблемы вовсе не те, что пытаются решать создатели современного С++ своими дополнительными проверками корректности типов или raii, либо этих мер все равно недостаточно.
Можно от абстрактных рассуждений перейти к конкретике? Озвучьте, пожалуйста, пример подобной "основной сложности".
А то ведь может оказаться, что главную роль в борьбе с ней будут играть проектные решения, а языковые возможности разве что позволят сократить количество рутины.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, lpd, Вы писали:
S>А то ведь может оказаться, что главную роль в борьбе с ней будут играть проектные решения, а языковые возможности разве что позволят сократить количество рутины.
Именно это я и имею ввиду.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
S>>А то ведь может оказаться, что главную роль в борьбе с ней будут играть проектные решения, а языковые возможности разве что позволят сократить количество рутины.
lpd>Именно это я и имею ввиду.
Т.е., если C++ позволяет сократить количество рутины по сравнению с чистым C в разы (а то и на порядок-другой), то это не считается?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, lpd, Вы писали:
S>>>А то ведь может оказаться, что главную роль в борьбе с ней будут играть проектные решения, а языковые возможности разве что позволят сократить количество рутины.
lpd>>Именно это я и имею ввиду.
S>Т.е., если C++ позволяет сократить количество рутины по сравнению с чистым C в разы (а то и на порядок-другой), то это не считается?
Чем лучше архитектура и проще код, тем легче в программе искать ошибки, легче добавлять новые функции, и легче оптимизировать по скорости. Современный С++ же код значительно усложняет, особенно мув-семантика, умные указатели(по сравнению с GC), сложные шаблоны. Причем все это сделано вроде как для скорости, оправданность чего и вызывает сомнения.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
lpd>Чем лучше архитектура и проще код, тем легче в программе искать ошибки, легче добавлять новые функции, и легче оптимизировать по скорости. Современный С++ же код значительно усложняет, особенно мув-семантика, умные указатели(по сравнению с GC), сложные шаблоны. Причем все это сделано вроде как для скорости, оправданность чего и вызывает сомнения.
Тебя никто не заставляет использовать все возможности языка C++ и стремиться к максимальной производительности. Плюсы — это практичный язык, в нем есть множество инструментов для разных задач. Если тебе нужен простой код — пиши простой код. Не нужно зацикливаться на скорости работы кода, когда для тебя это не приоритет. Можешь не использовать семантику перемещения или сложные шаблоны, если они не нужны для решения твоей задачи. Никто тебя не заставляет писать на C++ максимально быстрый код (это тебе решать какой будет код и какими инструментами ТЫ будешь пользоваться).
Однако, C++ дает возможность писать в том числе и максимально быстрый код, поэтому ручное управление памятью (совместить его со сборкой мусора, пока, никому не удалось — либо оно не работает, либо неоправдано сложно).
IMHO, по количеству разных возможностей для решения широкого круга задач, лучше C++ ничего нет. Потому он и сложный. Но ты можешь использовать только нужные тебе инструменты и тогда он станет сильно проще.
Здравствуйте, IID, Вы писали:
Pzz>>Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать.
IID>То ли дело в чистом си! Нужна копия сокета при accept — выделим память и алга в нее memcpy. В результате CVE-2017-8890, чудесная дырочка, через которую буханки трескались как орешки. С success rate выше 98% (сорян, но выиграть две гонки с 100% рейтом это уже фантастика).
Ну давайте теперь будем каждый байт через конструктуры с проверками копировать. У Пентиума мегагерцев много, на всех хватит.
Здравствуйте, CreatorCray, Вы писали:
Pzz>>Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать. В новомодном C++ для этого, наверное, уже придумали какой-то навороченный синтаксис, состоящий из необычного сочетания обычных знаков препинания , но слабо могу себе представить, чтобы простой программист в своей прикладной программе им воспользовался.
CC>Ух жесть, я даже не думал что степень твоего непонимания простирается настолько глубоко!
И что, C++ научился вставлять в середину вектора, просто копируя хвост, как память, с места на место? Или это типа никому не надо, потому что не типабезопасно?
Здравствуйте, Masterspline, Вы писали:
M>IMHO, по количеству разных возможностей для решения широкого круга задач, лучше C++ ничего нет. Потому он и сложный. Но ты можешь использовать только нужные тебе инструменты и тогда он станет сильно проще.
В таком варианте в принципе да, только сейчас во всех вакансиях зачем-то требуют C++17, что вызывает сомнения, не применяют ли они его везде в действительности — любители есть и на этом форуме.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
_>Если же говорить о конкретных технических моментах, то тут есть целый ряд нюансов. Во-первых статический полиморфизм гарантирует корректность кода, т.к. всё проверяется компилятором на стадии сборки и не может случиться ситуация с неверно переданным указателем. Во-вторых естественно вопрос производительности. Статический полиморфизм очевидно на порядки эффективнее, т.к. вызов не просто идёт напрямую (а не косвенно, как в случае виртуальной функции), но и практически гарантированно инлайнится.
Представляю, во что превратится код программы, если в гуйне каждая кнопка поинлайнится.
Здравствуйте, lpd, Вы писали:
lpd>Чем лучше архитектура и проще код, тем легче в программе искать ошибки, легче добавлять новые функции, и легче оптимизировать по скорости. Современный С++ же код значительно усложняет, особенно мув-семантика, умные указатели(по сравнению с GC), сложные шаблоны. Причем все это сделано вроде как для скорости, оправданность чего и вызывает сомнения.
Во-первых, C++ был, есть и будет в обозримом будущем языком без GC. Соответственно там, где GC дает 100500 к простоте и надежности, C++ в настоящее время вряд ли должен использоваться.
Во-вторых, в контексте разговора "С++ против чистого Си" сложно представить как можно сделать "лучше архитектуры и проще код", если Си вообще не дает никаких абстракций.
В-третьих, хотелось бы все-таки примеров. Вот, мол, на C++11/14/17 получается вот такая непонятная и неподдерживаемая каша, а на чистой ламповой сишечке всего три строки простого, читаемого и надежного кода.
Здравствуйте, lpd, Вы писали:
lpd>В таком варианте в принципе да, только сейчас во всех вакансиях зачем-то требуют C++17, что вызывает сомнения, не применяют ли они его везде в действительности — любители есть и на этом форуме.
Если проект разрабатывается на C++ и нет принципиальных ограничений на версию C++ стандарта (вроде привязки к какому-то старому LTS-дистрибутиву Linux-а или использования специфического компилятора для специфической платформы), то нет смысла в отказе от C++17. Даже больше: нужны убедительные доводы для того, чтобы отказываться по каким-то причинам от C++17.
Здравствуйте, Pzz, Вы писали:
Pzz>И что, C++ научился вставлять в середину вектора, просто копируя хвост, как память, с места на место? Или это типа никому не надо, потому что не типабезопасно?
Ты в assembly хоть посмотрел? Современные компиляторы умеют распознавать копирование поэлементно и менять на memmove intrinsic.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Marty, Вы писали:
M>Такое бывает, да. Но кто знает, если бы он выбрал плюсики, возможно линупс завоевал бы десктоп уже году к двухтысячному.
Линукс завоевал мир серверов, включая сегмент высоконагруженного mission critical hi-end-а, вытеснив оттуда проприетарные юниксы, линукс вытестнил винду из сегмента серверов уровня предприятия, 100% суперкомпьютеров на линуксах, львиная доля мобильных и встраиваемых устройств на линуксах. И на десктопах он представлен в малом количестве совершенно не по причине того, что ядро на Сях написано. У Вас какие-то детские понятия вообще.
Здравствуйте, so5team, Вы писали:
S>Ну а на счет того, как пишется СУБД Oracle погулите нашумевший недавно инсайд о том, насколько там все гладко и замечательно.
Не надо мне гуглить, я его тут впервые и выкладывал в одном коменте. И да, это практика разработки того самого промышленного софта, масштабных промышленных систем. Почти везде так. Тут другое. Вот ответьте на следующий вопрос: такие компании как оракел тратят на оптимизации, рефакторинг, аудит и т.д кода кучи денег, привлекают мощных спецов каких только можно, за любые деньги. Так вот, если современный C++ есть кладезь истины и вселенской мудрости, обеспечивает написание более производительного, стабильного кода, причём написания быстрого, то почему оракел и подобные системы до сих пор на чистых Сях или в крайнем случае на Сях с классами? Только не надо тут про то, что корпорации экономят или не могут найти спецов по C++ (их реально полно) чтоб всё переписать. Более того, такие попытки предпринимались и предпринимаются не раз. Но не получается переписать эти системы на C++ какие бы спец не брались. Тут в треде уже упоминал про обломавших рога C++-ников на системах высокочастоного трейдинга. Вот почему?
Здравствуйте, Basil2, Вы писали:
B>Впервые за почти 10 лет начал искать работу. И с удивлением обнаружил, что на плюсах почти не осталось обычной работы.
B>Практически все вакансии требуют специфического опыта: B>- embedded B>- графика или игры B>- OpenCV и прочий ML B>- крипта, блокчейн или алготрейдинг B>- серверы и сервисы с высоконагруженностью и многопоточностью
B>И почти не осталось вакансий, где просто требуется хорошее знание С++.
Почему это так?
B>Что для меня весьма печально, т.к. как-то не довелось погрузиться в вышеозначенные области
Аналогично.
Я кодил (и кожу) решение сложных математических задач.
Почему схлопывается такой хороший, мощный (пусть и сложный) язык программирования?
Здравствуйте, smeeld, Вы писали:
S>Так вот, если современный C++ есть кладезь истины и вселенской мудрости
Это не так. Но ведь вам важнее эмоционально оправдать то, почему вы замшелый старпёр, а не разобраться в достоинствах и недостатках C++.
S>обеспечивает написание более производительного, стабильного кода, причём написания быстрого, то почему оракел и подобные системы до сих пор на чистых Сях или в крайнем случае на Сях с классами?
Потому что big rewritting очень редко заканчивается успешно. Тому куча причин. Например, потому, что у вас есть крайне непростой выбор:
— либо остановить развитие старой версии вообще и сконцентрироваться только на новой, тем самым теряя часть своего рынка;
— либо вести одновременно разработку двух версий, что означает удвоение затрат и учетверение геморроя, связанного с присутствием двух одновременно живых линеек продуктов.
S>Более того, такие попытки предпринимались и предпринимаются не раз.
У MS с его SQLServer-ом вроде как получилось.
S>Тут в треде уже упоминал про обломавших рога C++-ников на системах высокочастоного трейдинга. Вот почему?
Конкретно про ваш пример с трейдингом можно смело предположить, что там было слишком много замшелых старпёров, клепающих говнокод.
Вы вот не можете освоить преимущества С++. И если таких как вы больше 50-60%, то шансов на успех нет от слова совсем.
Кстати говоря, вот диды из GNU тридцать лет писали, писали GCC на чистом C, но дальше все равно были вынуждены перейти на C++.
Здравствуйте, Marty, Вы писали:
M> Вирусов под него мало, да — потому что на десктопе его исчезающе мало, и он просто не интересен вирусописателям
Бро, линукс лидирует на серверах, прежде всего на серверах интернет ресурсов, где он вообще уже дефолтный вариант. И сервер-это на порядки более значимая цель для молварей всех типов, чем десктопы хомячков или офисного планктона. Так что про вирусы мимо.
, но слабо могу себе представить, чтобы простой программист в своей прикладной программе им воспользовался.
