Здравствуйте, lpd, Вы писали:
_>>Т.е. если когда-нибудь C++ и потеряет свои лидирующие позиции, .. lpd>Только сделаю уточнение, что лидирующие позиции C++ получил задолго до C++14.
Безусловно.
Но если бы язык остановился в развитие (как кстати было в 2000-ых, когда тогдашний лидер в C++ (Microsoft) его забросил), то при появление приличной замены, его бы мгновенно сменили. Т.е. если бы C++11/14 не появился, то например я бы уже давно сидел на Rust'е. А так, при текущем развитие ситуации, и не факт что вообще когда-нибудь перейду (во всяком случае в данный момент от подобного перехода было бы больше минусов, чем плюсов).
Здравствуйте, smeeld, Вы писали:
_>>Т.е. если когда-нибудь C++ и потеряет свои лидирующие позиции S>Где Вы увидели лидирующие позиции C++? Во всех рейтингах которые только есть он стоит после Java, Python, Си. Причём в числах, С++ от Cи отстаёт в два раза.
Так ты уже пишешь это сообщение из браузера, написанного на C? Если ещё нет, то беги срочно писать вменяемую замену на C! А то ведь непорядок какой-то, весь мир сидит на не правильно написанных продуктах.
Да, и насчёт лидирующих Java и Python ты тоже хорошо упомянул — кода пойдёшь переписывать их с C++ на C?
Здравствуйте, Pzz, Вы писали:
_>>Да, а если какой-нибудь неадекват захочет вдруг пофантазировать на тему того, что в будущем пропадёт сама ниша системных яызков, то я даже не буду перечислять бесконечные ряды инфраструктурного ПО, а сразу зайду с банальных (но от этого не становящихся слабее) козырей: спрошу, а на каком языке будет написан рантайм (JVM, CLR, CPython, V8 и т.п.) его языка будущего? Pzz>Рантайм Go написан, чуть менее, чем полностью, на Go.
Хы, у Go нет рантайма в том смысле (виртуальной машины), в котором это слово упоминалось в контексте выше — он компилируется сразу в машинные коды. Но если же говорить в широком смысле слова (в котором рантайм есть и у C/C++), то значительная часть там написана конечно же не на Go, а на банальном ассемблере, отдельно под каждую платформу: https://github.com/golang/go/tree/master/src/runtime.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Вы представляете, в C++ можно в одном месте хранить std::chrono::seconds, в другом std::chrono::milliseconds, в третьем std::chrono::minutes НС>Вместо того чтобы везде хранить все в TimeSpan
Это который с фиксированной точностью 100 нс?
Уже десяток лет назад аппаратные таймеры шли с 10-нс разрешением, сегодня в среднем 1 нс.
TimeSpan публично выдаёт и вовсе микросекунды, а фактическую точность Ticks не декларирует и не гарантирует, ограничиваясь implementation-defined оговорками, мол, вот на такой-то архитектуре это столько-то.
В итоге имеет имеет слишком большую точность там, где не надо (занимая 64 бита, хотя в 99% этого не требуется) и недостаточную точность там, где надо (те самые 1%, когда привычно вспоминаешь всех матерей всех разработчиков дотнетных либ, вместе взятых).
В общем, мне пришлось перетянуть на дотнет немного из модели плюсового chrono, бо там степень продуманности натурально несравнимая рядом с TimeSpan.
TimeSpan был оправдан в первом дотнете, но уже во втором должны были появиться вменяемые альтернативы.
Здравствуйте, Marty, Вы писали:
M>MS, сделав ставку на дот нет, как ранее борман на делфю — долго задвигали C++ на второе место, но так и не получили в итоге, что хотели. Теперь наверстывают.
Кстате, они и в дотнете навёрстывают.
И все более в плане нормального нейтива в языке.
(unmanaged по их идиотской терминологии а-ля "я вещь сама в себе, и плевать на хороший тон, принятый в остальном мире", даже одноимённое ключевое слово ввели для ограничений генериков)
M>Ну, и очнувшийся наконец от комы комитет, который теперь, как я понимаю, нацелился выпекать новые стандарты языка каждые три года, даст просраться конкурентам.
От комы его очнули банальным образом — перетасовкой кадров (заменой одних, привлечением других).
M>Отдельные приложения сейчас уже не так модно писать — сейчас всё больше облака, белокрылые лошадки, и тп. Но ниша всё равно есть, и в этой нише плотно обосновался Qt. С новыми стандартами C++ и на нем стало гораздо приятнее.
Дело не только в стандарте С++, а в изменившемся подходе — теперь стоит плясать от декларативного QML, а конечный бинарь можно получить через Qt Quick Compiler.
Т.е., все "ужасы QT" можно оставить "под капотом" и никогда туда не заглядывать.
M>Сишечка — она окончательно займет место кобола нового времени. У многих контор будет огромная сишечная работающая котобаза, которую менять особо не надо, нужно будет только допиливать понемногу всякие интеграции с современным C++. В них найдут пристанище всё эти массы пенсионеров, умеющие в C++98/03.
Или пока не появится некая версия С-- (урезанного С++) специально для написания ядер операционок и вообще низкоуровневого софта.
EC++ — это ж был эпик фейл, там малость перестарались с ограничениями.
Сегодня Си поддерживает на плаву только код исходников ведущих операционок.
И этот код активно развивается, что, увы, продолжает подкреплять позиции Си.
Здравствуйте, alex_public, Вы писали:
_>Т.е. если когда-нибудь C++ и потеряет свои лидирующие позиции, то это произойдёт из-за его замены Rust'ом (который кстати является как раз развитием идей современного C++, только пошёл ещё дальше, жёстко зафиксировав в синтаксис то, что в современном C++ считается негласными правилами написания нормального ПО)
Глядя на некоторые драфты для слишком будущих версий плюсов, боюсь, Rust-у уготована роль эдакого полигона для обкатки идей из мира нейтивного программирования.
Его ж всё-равно не жалко, индустрия на него никак не завязана.
А наработки затем спокойно уйдут в С++.
Причём, этот процесс может быть довольно-таки длительным по кругу, т.е. быть повторённым не один раз.
_>Да, а если какой-нибудь неадекват захочет вдруг пофантазировать на тему того, что в будущем пропадёт сама ниша системных яызков, то я даже не буду перечислять бесконечные ряды инфраструктурного ПО, а сразу зайду с банальных (но от этого не становящихся слабее) козырей: спрошу, а на каком языке будет написан рантайм (JVM, CLR, CPython, V8 и т.п.) его языка будущего?
Зря ты так. ))
Это больной мозоль.
Они ж нервно реагируют на С++ не потому, что язык плохой (в мире полно куда как более плохих языков, просто ужасных, но их бьют куда как реже или не бьют вовсе), а потому что С/С++ находятся на вершине пищевой цепочки современного IT. Все эти JVM/v8 и Ко подкидывают пищу нейтивным разработчикам одним своим существованием.
Может, и не хотели бы, но не могут не подкидывать, бо сами растут из нейтива.
В принципе, ничего страшного, обычная инженерия здорового человека, но некоторых несознательных аж крючит, смотрю.
Всё-таки, справедливости ради, ассемблер этот не банальный, а переносимый Go-ассемблер. Гениальное решение; по крайней мере, никто не станет писать на нём высокоуровневый код, как это случилось с другим языком, носившем прозвище "переносимый ассемблер".
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>Вы представляете, в C++ можно в одном месте хранить std::chrono::seconds, в другом std::chrono::milliseconds, в третьем std::chrono::minutes НС>>Вместо того чтобы везде хранить все в TimeSpan
V>Это который с фиксированной точностью 100 нс? V>Уже десяток лет назад аппаратные таймеры шли с 10-нс разрешением, сегодня в среднем 1 нс.
Очень актуально в свете того, что надо в конфигах хранить секунды и минуты.
Здравствуйте, alex_public, Вы писали:
_>Хы, у Go нет рантайма в том смысле (виртуальной машины), в котором это слово упоминалось в контексте выше — он компилируется сразу в машинные коды. Но если же говорить в широком смысле слова (в котором рантайм есть и у C/C++), то значительная часть там написана конечно же не на Go, а на банальном ассемблере, отдельно под каждую платформу: https://github.com/golang/go/tree/master/src/runtime.
На асме там написан стартап, очень низкоуровневые процедуры, типа доступа к TLS, которых там совсем немного, и процессорно-специфические оптимизации.
Для x86, например, там всего полторы тысячи строк ассемблера, включая коментарии. Причем туда еще зачем-то и AES запихнули.
В сишном рантайме доля ассемблера и его назначение примерно такие же.
Здравствуйте, alex_public, Вы писали:
_>Это само собой. Но ты же говорил, что у тебя перловский скрипт работал столько же, сколько и C++ программа с отключённым освобождением памяти. А это уже однозначно намекает на какой-то косяк в коде. )
Каким образом намекает? Перловский скрипт и C++ программа без освобождений отрабатывали быстро, но я не заморачивался с миллисекундной точностью мерить. C++ с освобождениями отрабатывал ОЧЕНЬ медленно.
Здравствуйте, Marty, Вы писали:
M>Ну, на пёрле это мог быть один большой регэксп, например. На грани того, что еще может быть написан человеком. Прекомпилируешь его, потом натравливаешь на данные — профит. Тут плюсики и в правду не нужны
Ну нет, там окромя возни со строками, была еще довольно сложная переработка данных. Я бы удавился делать это на регекспах
Здравствуйте, Kswapd, Вы писали:
K>Всё-таки, справедливости ради, ассемблер этот не банальный, а переносимый Go-ассемблер. Гениальное решение; по крайней мере, никто не станет писать на нём высокоуровневый код, как это случилось с другим языком, носившем прозвище "переносимый ассемблер".
Говорят, его таким Керниган изобрел еще во времена доисторического юникса.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, so5team, Вы писали:
S>>AFAIK не только. Еще он используется в авиации, медицине и энергетике.
L>В передаче и распределении? О нем легенды ходят. В смысле, что Аду там в глаза не видели, только легенды рассказывают. L>Про область генерирования энергии (большие электростанции) не расскажу, не знаю.
На Highload++ на прошлой неделе был доклад про систему управления АЭС. Докладчик — Вадим Подольный, завод Физприбор. Технологии — C, C++, QNX.
Здравствуйте, AleksandrN, Вы писали:
L>>Про область генерирования энергии (большие электростанции) не расскажу, не знаю.
AN>На Highload++ на прошлой неделе был доклад про систему управления АЭС. Докладчик — Вадим Подольный, завод Физприбор. Технологии — C, C++, QNX.
Сомневаюсь, что на российских АЭС вообще применяется софт, разработанный на Ada (как и сильно сомневаюсь, что есть российские сертифицированные для подобных нужд компиляторы Ada). Применение Ada нужно искать на американских/европейских станциях. Типа вот такого: http://archive.adaic.com/projects/atwork/nuclear.html
Здравствуйте, so5team, Вы писали:
S>Сомневаюсь, что на российских АЭС вообще применяется софт, разработанный на Ada (как и сильно сомневаюсь, что есть российские сертифицированные для подобных нужд компиляторы Ada). Применение Ada нужно искать на американских/европейских станциях. Типа вот такого: http://archive.adaic.com/projects/atwork/nuclear.html
Непосредственным управлением оборудованием занимаются PLC, которые по сути программируемые конечные автоматы, сильно ограничивающие инженеров в выборе инструментов для стрельбы по ногам. Сомневаюсь, что существуют прошивки для PLC, написанные на ADA.
Над PLC сидят АСУТП (читай SCADA) — наиболее распространненые в мире SCADA системы написаны на плюсах, а то и шарпе.
Здравствуйте, landerhigh, Вы писали:
S>Типа вот такого: http://archive.adaic.com/projects/atwork/nuclear.html
L>Непосредственным управлением оборудованием занимаются PLC, которые по сути программируемые конечные автоматы, сильно ограничивающие инженеров в выборе инструментов для стрельбы по ногам. Сомневаюсь, что существуют прошивки для PLC, написанные на ADA. L>Над PLC сидят АСУТП (читай SCADA) — наиболее распространненые в мире SCADA системы написаны на плюсах, а то и шарпе.
Я привел ссылку. Она подтверждает, что Ada используется в энергетике. Утверждений о том, что Ada широко используется в энергетике, что кроме Ada в энергетике ничего больше не используется, что на Ada пишутся наиболее критичные места и пр. не было.
