а при чём тут "все-все" вообще? вот у Нидерланд нет ни какой войны с Китаем но чет ASML не может им продать свои литографы и не потому что Китай не хочет их покупать, не подскажешь как же так вышло?
Объясняю на пальцах, для таких как ты, задача всего этого производства в создании полной автономии в критических информационных инфраструктурах, что б картельный сговор различных стран не мог влиять на стабильность РФ своими идиотскими санкциями. Чтоб не было проблем с заменой критически важных узлов в условной АЭС.
И вообще не важно сколько это производство будет стоить и будет ли оно окупаться если эти деньги тратятся внутри страны, на производство внутри страны и на зарплаты граждан этой страны. Или когда под угрозой остановки могут оказаться такие объекты как АЭС или ТЭЦ.
Что ты там считал я хз, ты даже приблизительно не понимаешь о чем говоришь.
мдаа.. как же ты слабо понимаешь на сколько огромная промышленность и как много всего завязано но низко производительных чипах.. как думаешь сколько электроники в одном только атомном ледоколе? а в АЭС, нефтевышке? хотя бы представляешь какое количество этих нефтевышек, а сколько ТЭЦ, ГЭС и АЭС в стране, сколько трубопроводов, канализаций и какое количество АСУ ТП в этом всём, и это не говоря про военную промышленность, ракеты, авиацию, флот, тяжёлую бронетехнику и всех сопутствующих секторов промышленности которые стоят перед этим начиная от добычи энергоресурсов и заканчивая производством условного танка, сектор настольных железок с этими объёмами даже близко не валяется.
И ни кто не собирается производить свои версии x86 для замены интела тем более в потребительском секторе домашних пк.
потому что основная задача всего этого действия по созданию литографов и процессоров это переход на отечественную электронику в сфере оборонной, энергетическиой и прочих жизненно важных сферах государства, цели производить десктопные процы для домохозяек ни когда и не было это бредовые воображения людей мало понимающих для чего это все вообще делается.
согласен только касаемо "привычный вид элементов интерфейса" и то это спорный аргумент, благодаря засилию веб технологий для отрисовки гуи сейчас иметь нативный вид элементов вообще не в тренде, можно открыть 10 своих самых "любимых" приложений и не увидеть там ни одного нативного элемента.
а по поводу всего остального, чего из перечисленного нет тут, тут или тут
в qt можно зарендерить чтоб кнопка при нажатии например взрывалась на партикли? если да то я этого реально не знал. И не совсем понял про "только вулкан" imgui поддерживает вообще любой рендерер который умеет треугольники рисовать. Ну и я не спорю что для больших приложений qt гораздо проще и быстрее использовать, по крайней мере пока что.
что может быть более кастамизируемо чем прямое взаимодейтсвие с шейдерами и всем остальным конвейером рендеринга без каких либо промежуточных API OS?))
за давностью разбирательства с этой проблемой не могу говорить с уверенностью, но для того чтоб линковаться с musl нужно подменять загрузчик и при наличии "закрытых" зависимостей собранных с glibc это может взорвать приложение.
тут речь не про рядовые зависимости типа boost, а что то в духе libatomic, pthread и с ними ещё можно относительно просто разобраться, а вот чтоб изолироваться от glibc это нужно столько приседаний сделать что одуреть можно, а в большинстве кодовых баз эти приседания в принципе не возможны (если интересны детали есть отличный доклад про это https://youtu.be/Z7WuUhPJ-cU)
В win чтоб запускать прогу собраную самым последним тулчейном vc на win7 достаточно просто поставить последний пакет Redistributable C++, а под linux чтоб мне запустить хоть что то собранное последним gcc на условной ubuntu 12.04 в общем случае вообще ни чего не сделать это практически нереально без полного обновления ОС включая ядро. найс портируемость linux.
мм, язык с 40 летним опытом, кучей тулинга, комунити, десятками ide или же язык не выбравшийся из пеленок, хмм, ну выбор очевидный конечно)..
Страшно что это UB,
меня мало интересуют синтетические примеры, можно пример из жизни вот у нас оказалось переполнение и все взорвалось? А бесконечные циклы и без переполнения знаковых могут случится и не только в С++, детектится это на раз два по дампу или профайлеру, да и отлавливается ещё на этапе статических анализаторов обычно.
Мнение Microsoft и Android (Google) для вас тоже ничего не значит? А как насчет Линуса Торвальдса?
Линуса значит, вот только то что он согласился на поддержку раста как языка для драйверов ни какого отношения к "не безопасности" C++ не имеет, и его претензии к плюсам в целом мне понятны и в большинстве своём обоснованы , но они опять же ни как не связаны с "не бесопасным кодом"
так что С, но не С++
ты же знаешь что glibc в андроиде на C++ написан? и то что не проблема писать на С++ и иметь при этом внешний апи на C?
Но процесс идет
ну это только время покажет, эти мантры уже были за последние 30 лет и не раз так что очень слабо верится что что то изменится
ну предположим нельзя, хотя мне кажется можно найти нетривиальные кейсы когда CSharp взаимодействует с какими ни будь ресурсами типа COM, но ценой чего? добавления GC? потерями перфоманса или часовыми плясками во круг borrow checker чтоб он соизволил понять что тут всё нормально?
а что собственно страшного в переполнении signed int и в чем принципиальное отличие от того что в других языках оно defined behavior хотя и делает тоже самое? я видимо просто не работал там где это критичная проблема хотелось бы понять проблематику, а то столько раз уже про это слышал но не разу не видел
вот уж чьё мнение меня меньше всего интересует в вопросах "безопасности кода" так это агентства по слежке и созданию 0 day уязвимостей везде где сможет дотянутся.
В худшем случае это запортит очень важные данные,
в других языках же такого не бывает совсем, привет от Log4j. Но почему то все критически важные узлы чувствительные ко взлому и отказоустойчивости всё равно пишутся на C и С++
Очевидно что в других языках часть багов не возможна
это какие и в каких что их прям "не может быть"? утечка памяти и ресурсов в целом в языка с GC вроде как не уникальное явление, так же как и выход за границы, обращение к неинициализированным данным, дедлоки и всё остальное.
к обычному падению с ошибкой и стектрейсом.
а в C++ какое то необычное падение и стектрейсы? или оно в случае ошибки берет и сносит ОС? если мы конечно сравниваем языки в одинаковых задачах
не аргумент.
конечно аргумент ведь зачем они тратят усилия на всё это если cчитают C++ таким не исправимым, ну или там есть некий контекст все же, а не просто заявления в стиле "бегите глупцы" какими их обычно пытаются представить раст фанатики.
И в зависимостях зависимостей проверяете?)
Ты либо весь код собираешь с санитайзерами либо ни какой, мне трудно представить как собрать половину так половину сяк.
а он до сих пор впадает в панику когда память не получается выделить или с этим уже что то сделали? сор не особо слежу за развитием
тогда не задавай глупых вопросов
а при чём тут "все-все" вообще? вот у Нидерланд нет ни какой войны с Китаем но чет ASML не может им продать свои литографы и не потому что Китай не хочет их покупать, не подскажешь как же так вышло?
Прочитай хотя бы заголовок статьи, на кой ты лезешь в спор не понимая о производстве чего идёт речь?
Дно, это уровень твоего образования.
Объясняю на пальцах, для таких как ты, задача всего этого производства в создании полной автономии в критических информационных инфраструктурах, что б картельный сговор различных стран не мог влиять на стабильность РФ своими идиотскими санкциями. Чтоб не было проблем с заменой критически важных узлов в условной АЭС.
И вообще не важно сколько это производство будет стоить и будет ли оно окупаться если эти деньги тратятся внутри страны, на производство внутри страны и на зарплаты граждан этой страны. Или когда под угрозой остановки могут оказаться такие объекты как АЭС или ТЭЦ.
Что ты там считал я хз, ты даже приблизительно не понимаешь о чем говоришь.
мдаа.. как же ты слабо понимаешь на сколько огромная промышленность и как много всего завязано но низко производительных чипах.. как думаешь сколько электроники в одном только атомном ледоколе? а в АЭС, нефтевышке? хотя бы представляешь какое количество этих нефтевышек, а сколько ТЭЦ, ГЭС и АЭС в стране, сколько трубопроводов, канализаций и какое количество АСУ ТП в этом всём, и это не говоря про военную промышленность, ракеты, авиацию, флот, тяжёлую бронетехнику и всех сопутствующих секторов промышленности которые стоят перед этим начиная от добычи энергоресурсов и заканчивая производством условного танка, сектор настольных железок с этими объёмами даже близко не валяется.
И ни кто не собирается производить свои версии x86 для замены интела тем более в потребительском секторе домашних пк.
потому что основная задача всего этого действия по созданию литографов и процессоров это переход на отечественную электронику в сфере оборонной, энергетическиой и прочих жизненно важных сферах государства, цели производить десктопные процы для домохозяек ни когда и не было это бредовые воображения людей мало понимающих для чего это все вообще делается.
Вот бы ещё исходники компилятора открыли
согласен только касаемо "привычный вид элементов интерфейса" и то это спорный аргумент, благодаря засилию веб технологий для отрисовки гуи сейчас иметь нативный вид элементов вообще не в тренде, можно открыть 10 своих самых "любимых" приложений и не увидеть там ни одного нативного элемента.
а по поводу всего остального, чего из перечисленного нет тут, тут или тут
в qt можно зарендерить чтоб кнопка при нажатии например взрывалась на партикли? если да то я этого реально не знал. И не совсем понял про "только вулкан" imgui поддерживает вообще любой рендерер который умеет треугольники рисовать. Ну и я не спорю что для больших приложений qt гораздо проще и быстрее использовать, по крайней мере пока что.
что может быть более кастамизируемо чем прямое взаимодейтсвие с шейдерами и всем остальным конвейером рендеринга без каких либо промежуточных API OS?))
то что требует он свой загрузчик
что же тогда в документации другое сказано? https://wiki.musl-libc.org/faq#Q:-Where-is-<code>ldd</code>
за давностью разбирательства с этой проблемой не могу говорить с уверенностью, но для того чтоб линковаться с musl нужно подменять загрузчик и при наличии "закрытых" зависимостей собранных с glibc это может взорвать приложение.
тут речь не про рядовые зависимости типа boost, а что то в духе libatomic, pthread и с ними ещё можно относительно просто разобраться, а вот чтоб изолироваться от glibc это нужно столько приседаний сделать что одуреть можно, а в большинстве кодовых баз эти приседания в принципе не возможны (если интересны детали есть отличный доклад про это https://youtu.be/Z7WuUhPJ-cU)
В win чтоб запускать прогу собраную самым последним тулчейном vc на win7 достаточно просто поставить последний пакет Redistributable C++, а под linux чтоб мне запустить хоть что то собранное последним gcc на условной ubuntu 12.04 в общем случае вообще ни чего не сделать это практически нереально без полного обновления ОС включая ядро. найс портируемость linux.
Аксиома Эскобара
мм, язык с 40 летним опытом, кучей тулинга, комунити, десятками ide или же язык не выбравшийся из пеленок, хмм, ну выбор очевидный конечно)..
меня мало интересуют синтетические примеры, можно пример из жизни вот у нас оказалось переполнение и все взорвалось? А бесконечные циклы и без переполнения знаковых могут случится и не только в С++, детектится это на раз два по дампу или профайлеру, да и отлавливается ещё на этапе статических анализаторов обычно.
Линуса значит, вот только то что он согласился на поддержку раста как языка для драйверов ни какого отношения к "не безопасности" C++ не имеет, и его претензии к плюсам в целом мне понятны и в большинстве своём обоснованы , но они опять же ни как не связаны с "не бесопасным кодом"
ты же знаешь что glibc в андроиде на C++ написан? и то что не проблема писать на С++ и иметь при этом внешний апи на C?
ну это только время покажет, эти мантры уже были за последние 30 лет и не раз так что очень слабо верится что что то изменится
и как тут поможет любой другой язык в такой ситуации и в чем тут вина с++?
если вам нужно делать что то большее чем добавить пару флагов для сборки в каком ни будь текстовом файлике то у вас большие проблемы с CI.
ну предположим нельзя, хотя мне кажется можно найти нетривиальные кейсы когда CSharp взаимодействует с какими ни будь ресурсами типа COM, но ценой чего? добавления GC? потерями перфоманса или часовыми плясками во круг borrow checker чтоб он соизволил понять что тут всё нормально?
а что собственно страшного в переполнении signed int и в чем принципиальное отличие от того что в других языках оно defined behavior хотя и делает тоже самое? я видимо просто не работал там где это критичная проблема хотелось бы понять проблематику, а то столько раз уже про это слышал но не разу не видел
вот уж чьё мнение меня меньше всего интересует в вопросах "безопасности кода" так это агентства по слежке и созданию 0 day уязвимостей везде где сможет дотянутся.
в других языках же такого не бывает совсем, привет от Log4j. Но почему то все критически важные узлы чувствительные ко взлому и отказоустойчивости всё равно пишутся на C и С++
это какие и в каких что их прям "не может быть"? утечка памяти и ресурсов в целом в языка с GC вроде как не уникальное явление, так же как и выход за границы, обращение к неинициализированным данным, дедлоки и всё остальное.
а в C++ какое то необычное падение и стектрейсы? или оно в случае ошибки берет и сносит ОС? если мы конечно сравниваем языки в одинаковых задачах
конечно аргумент ведь зачем они тратят усилия на всё это если cчитают C++ таким не исправимым, ну или там есть некий контекст все же, а не просто заявления в стиле "бегите глупцы" какими их обычно пытаются представить раст фанатики.
Ты либо весь код собираешь с санитайзерами либо ни какой, мне трудно представить как собрать половину так половину сяк.