Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от opennews (??), 04-Мрт-25, 22:03
Опубликован релиз проекта Memsafe,  реализующего механизм безопасной работы со ссылочными типами и динамической памятью в коде на языке С++. Защита может быть добавлена  без нарушения обратной совместимости со старым С++ кодом. Проект оформлен в виде одного заголовочного файла memsafe.h и плагина для компилятора Clang. Код распространяется под лицензией  LGPL 2.1... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62830
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–29 +/–
Сообщение от Аноним (1), 04-Мрт-25, 22:03
Прикольно, С++ превращается в уродливый Rust. Т.е. судя по вайбу (последним новостям), диды таки признали что это реально проблема, а на раст перейти нельзя из-за кучи легаси кода и лени учить новый язык. Ну кто бы сомневался, все заминусованые местными хомячками давно об этом говорили. Грядётъ.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Дед (??), 04-Мрт-25, 22:11
	>а на раст перейти нельзя из-за кучи легаси кода и лени учить новый язык. Всё это требует зарплату и не одну (по времени), и не на одного. Мораль: работает - не трогай, иначе сам за всё ответишь.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от НяшМяш (ok), 04-Мрт-25, 22:29
	> работает - не трогай Но ведь не работает же. Особенно когда потрогал (а трогать надо - движение это жизнь) и сразу словил кучу CVE.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Dima (??), 04-Мрт-25, 23:16
	Как только что то на уровне С и С++ пишешь на рс, везде ансейф
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
	Сообщение от Аноним (41), 04-Мрт-25, 23:35
	ансейф по определению архитектура памяти твоей
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от px (??), 04-Мрт-25, 23:52
	У меня совсем другой опыт
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	37. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+6 +/–
	Сообщение от Аноним (37), 04-Мрт-25, 23:02
	>Мораль: работает - не трогай Это самое опасное заблуждение, которые засело в головах. Потому что оно консервирует техдолг. Вот так оно "работает не трогали" 30 лет, а потом новое поколение хватается за голову как этот кусок копролита развивать и масштабировать. В условиях, что половина стека передохла, ага.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	87. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–5 +/–
	Сообщение от Аноним (-), 05-Мрт-25, 05:48
	"Работает - не трожь" - это мораль русских сисадминов. Некоторые его переносят на другие сферы жизни. Тот Дед перевёл его в плоскость программирования. Ещё, слышал такую мораль - "Если хочешь нормально провести выходные, то не настраивай сервер в Пятницу". Это всё скорее не заблуждение, а национальная русская мораль.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+4 +/–
	Сообщение от Смузихлеб забывший пароль (?), 05-Мрт-25, 08:59
	т.е в сша в банковской сфере сисадминами и программистами сидят сплошь русские по национальности ?)
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аномалии (?), 05-Мрт-25, 09:14
	Не нужно путать системного администратора с эникеем. Опять во всем русские виноваты?
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	221. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от U202204161753 (?), 05-Мрт-25, 20:10
	> не настраивай сервер в Пятницу И? (  Вы "теоретик бизнеса"? )
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	95. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+4 +/–
	Сообщение от Аноним (95), 05-Мрт-25, 06:38
	При чем тут мораль. Если сервер настроен и работает, то не надо его трогать, это логично. Если после трогания сервер может простаивать, это убытки для бизнеса. Я периодически слышу критику принципа "работает не трогай". Критикуют этот принцип люди неопытные и некомпетентные, но очень сильно желающие себя проявить. Заканчивается это простоем серверов.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	102. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Вася Пупкин (?), 05-Мрт-25, 07:50
	Должны быть выстроены процессы с zero-down-time и прочим. Но куда до этого некомпитентным выскочкам. А евли вам страшно править уязвимости, то это конечно показывает опытность, да.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+5 +/–
	Сообщение от YetAnotherOnanym (ok), 05-Мрт-25, 11:29
	"Zero-down-time" - это очень дорогое удовольствие. Даже для очень солидных контор целесообразнее предупреждать клиентов о проведении работ (а для этого заранее внести в договор пункт о допустимом даунтайме), чем тратиться обеспечение настоящего "zero-down-time". Но куда там высококомпетентному эксперту опеннета до каких-то презренных денежных вопросов.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аномалии (?), 05-Мрт-25, 09:21
	С одной стороны правильно. Если все отлажено и нормально работает и не нужно в ближайшее время ничего улучшать и дыры исправлять, то да. В другом случае, как раз нужно трогать сервер и что надо менять и перенастраивать. Но только чтобы не было простоя нужно подходить к серверу с умом и определенными знаниями. Ну и перед этим все изменения нужно сначала на тестовом сервере проверить, а потом уже в прод
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	132. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (132), 05-Мрт-25, 09:30
	А потом тебе служба безопасности даёт ссылку на CVE кака раз на твою старую версию и ты в панике поднимаешь версию или увольняешься. Разве не так?
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	167. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от YetAnotherOnanym (ok), 05-Мрт-25, 11:39
	"Mitigation"? Не, не слышали. Когда публикуется CVE, затрагивающая установленный в хозяйстве софт, надо не в панике версию поднимать, а спокойно прикинуть, какие последствия эта CVE может иметь, и как их минимизировать или исключить какими-то вспомогательными мерами. А там и обновлённая версия в репах подоспеет, проверенная (кроме прочего) на отсутствие регрессий.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от BeLord (ok), 05-Мрт-25, 10:13
	Бизнес считает риски, в том числе того, что сервак упадет, а значит, либо у бизнеса есть резервные серваки, которые спокойно можно модернизировать, либо это не бизнес, а лавочники.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	99. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (99), 05-Мрт-25, 07:41
	и что ты предлагаешь? ты хоть раз сократил свой техдолг?
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	117. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Смузихлеб забывший пароль (?), 05-Мрт-25, 09:01
	Это не заблуждение. Это - реалии для сложных систем. Если оно долго проработало и потеряло актуальность - делается ТЗ, готовится документация и делается НОВЫЙ продукт согласно новым реалиям. И им постепенно, с допиливаниями, заменяют старый. А не лезут кривыми руками в старый, с кучей подпорок и который местами хз как вообще работает
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	126. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от diakin (ok), 05-Мрт-25, 09:15
	>Вот так оно "работает не трогали" 30 лет, а потом новое поколение хватается за голову.. Ну так напиши свое новое, хорошее.. Если есть за что хвататься конечно ))
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	7. Скрыто модератором	–4 +/–
	Сообщение от Bottle (?), 04-Мрт-25, 22:12
	Название Rust говорит само за себя - ржавление. Смысл языка в том, чтобы саботировать чужую работу через сообщество переписывателей и свидетелей безопасности в язычке без спецификации. Они бы ещё гнилью назвали свой проект, было бы точнее.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	13. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 04-Мрт-25, 22:25
	> Название Rust говорит само за себя - ржавление. Удивительно, но хейтерочки не знают, что Rust назван в честь очень живучих грибков. > Смысл языка в том, чтобы саботировать чужую работу через сообщество > переписывателей и свидетелей безопасности в язычке без спецификации. Смысл языка в том, чтобы показать тyпopылым дидам, что за 50 лет модели угроз изменились и из омнокоду не место в этом мире. А в перерывах можно их натыкать мордочкой в очередную CVE. > Они бы ещё гнилью назвали свой проект, было бы точнее. Тебя Иван покусал?
	Ответить | Правка | Наверх | Cообщить модератору

	17. Скрыто модератором	+/–
	Сообщение от НяшМяш (ok), 04-Мрт-25, 22:27
	Может его с работы выгнали, а вместо него взяли зумера с растом. Вот и борется так, как лучше всего умеет - в интернете.
	Ответить | Правка | Наверх | Cообщить модератору

	40. Скрыто модератором	+3 +/–
	Сообщение от maximnik0 (?), 04-Мрт-25, 23:16
	>что за 50 лет модели угроз изменились и из омнокоду Диды как раз и придумали аппаратную защиту памяти- атрибутная (контекстная)  защита.Да да, Эльбрус мягко говоря позаимствовал идею с Барроза.А тут разработчики  риск-5 обнаружил что патенты то истекли и внедрили защиту.У арм подгорело и в арм64 они тоже внедрили такую же защиту.А вот x64 грустно, приходится изобретать Раст,Яву и. Net.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	54. Скрыто модератором	+4 +/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 00:19
	Эльбрус смог, Арм смог, а Интел и АМД не смогли. Пришлось изобрести Раст и Яву. Не знаю, кто твой дилер, но товар у него отборный, это прям заметно.
	Ответить | Правка | Наверх | Cообщить модератору

	61. Скрыто модератором	+/–
	Сообщение от maximnik0 (?), 05-Мрт-25, 00:38
	> Не знаю, кто твой дилер, но товар у него отборный, это прям > заметно. Вы читали что такое атрибутная защита ? У x64 весит совместимость с x32 , вдобавок 1 бит уже зарезервирован за noexec .Откуда им взять биты для атрибутов для контекстной защиты,это нужно ломать совместимость.У арм64 для мобильника сделали специальный режим работы -для памяти зарезервировано 48 бит, остальные биты для атрибутов.Совместимость не сломана,т.к софта на 64 бита памяти не много (практически нет) , суперкомпьютер фуджитсу пожалуй единственный кто использует 64 бита для памяти.Мипс5 аналогично ,в разработке,софта не много.Эльбрус использует аппаратный финт ушами- аппаратные ЕСС коды коррекции ошибок памяти используется для атрибутов памяти,но это решение запатентовано, придется покупать лицензию :-) Так что не зря Интел спонсирует Раст,не все так просто.
	Ответить | Правка | Наверх | Cообщить модератору

	69. Скрыто модератором	–3 +/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 01:10
	> Вы читали что такое атрибутная защита ? Нет. И, судя по описанию, в ближайшее время не прочитаю. > Так что не зря Интел спонсирует Раст,не все так просто. Мой тейк вот к этому относится. Интел много чего поддерживает, и притянуть за уши можно любую теорию заговора.
	Ответить | Правка | Наверх | Cообщить модератору

	127. Скрыто модератором	+/–
	Сообщение от diakin (ok), 05-Мрт-25, 09:20
	Не читал, но осуждаю.. Ну, обычное дела, да.
	Ответить | Правка | Наверх | Cообщить модератору

	73. Скрыто модератором	+/–
	Сообщение от Аноним (73), 05-Мрт-25, 01:40
	> У арм64 для мобильника сделали специальный режим работы -для памяти зарезервировано 48 бит, остальные биты для атрибутов. у армов памперс ненадёжный оказался https://arxiv.org/pdf/2406.08719
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	81. Скрыто модератором	+/–
	Сообщение от maximnik0 (?), 05-Мрт-25, 03:37
	Атака позволяет определить содержимое атрибутов - ну определил а дальше то что? Все равно сложность  атаки для хакера очень возрастает, особенно с рандомизацией памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	105. Скрыто модератором	+/–
	Сообщение от Аноним (73), 05-Мрт-25, 08:22
	> ну определил а дальше то что? https://github.com/compsec-snu/tiktag?tab=readme-ov-file#rea...
	Ответить | Правка | Наверх | Cообщить модератору

	148. Скрыто модератором	+/–
	Сообщение от maximnik0 (?), 05-Мрт-25, 10:24
	>> ну определил а дальше то что? > https://github.com/compsec-snu/tiktag?tab=readme-ov-file#rea... Перевод описания Расширение тегов памяти ARM (MTE) - это функция ARMv8.5-A, предназначенная для смягчения атак с повреждением памяти. Гаджет TikTag ломает MTE, утекая теги MTE посредством спекулятивного выполнения. Когда гаджеты TikTag выполняются спекулятивно, состояние кэша различается в зависимости от того, вызывают ли гаджеты ошибку проверки тегов или нет. Следовательно, наблюдая за состояниями кэша, можно утечь результаты проверки тегов, не создавая никаких исключений. Гаджеты были эффективны как для Pixel 8, так и для Pixel 8 pro, которые являются первым оборудованием с официальной поддержкой MTE. Нечего нового ,в PDF я все прочел. Утечка тегов,определил ты тип тега ну - а ДАЛЬШЕ ТО ЧТО ? Что с этими тегами ты делать собираешься,солить ?  Да атака типа Спектра,плохо,но теги не секретная информация.
	Ответить | Правка | Наверх | Cообщить модератору

	158. Скрыто модератором	+/–
	Сообщение от Аноним (73), 05-Мрт-25, 10:44
	> Утечка тегов,определил ты тип тега ну - а ДАЛЬШЕ ТО ЧТО ? Что с этими тегами ты делать собираешься,солить ? ты под веществами чтоли ссылки открываешь > We crafted a TikTag-v2 gadget in JavaScript that can leak the tag of the entire renderer process memory space. Utilizing the leaked tag, this PoC exploits the recent heap overflow vulnerability CVE-2023-5217 in the libvpx library to bypass the MTE protection and trigger the memory corruption.
	Ответить | Правка | Наверх | Cообщить модератору

	161. Скрыто модератором	+/–
	Сообщение от maximnik0 (?), 05-Мрт-25, 11:02
	>CVE-2023-5217 in the libvpx library to bypass the MTE protection Не все правильно тегированно,софт нужно дополнительно адаптировать.Нашли слабо адаптированную библиотеку,всего лишь один тег на весь процесс- знали что в ней есть ошибка,вызвали функцию с переполнением,так обошли защиту. Нечего нового пока не вижу .Бит noexec тоже не панацеей оказался,научились обходить,но уже крутиться приходиться.
	Ответить | Правка | Наверх | Cообщить модератору

	77. Скрыто модератором	+2 +/–
	Сообщение от Аноним (73), 05-Мрт-25, 02:33
	> Эльбрус смог, Арм смог, а Интел и АМД не смогли. Пришлось изобрести Раст и Яву. примерно так да https://arxiv.org/abs/2203.04117 ну и скорей всего на практике кроме эльбруса ни у кого аппаратная защита не работает из-за спекуляций. Видимо смекнули что попали в просак и нагнули программистов - пусть ипутся переписывают на ослином языке
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	88. Скрыто модератором	+/–
	Сообщение от Аноним (88), 05-Мрт-25, 05:50
	> https://arxiv.org/abs/2203.04117 > ну и скорей всего на практике кроме эльбруса ни у кого аппаратная > защита не работает из-за спекуляций. Видимо смекнули что попали в просак > и нагнули программистов - пусть ипутся переписывают на ослином языке Какие затейники. Это многое объясняет. Т.е. вся проблема в hardware от Intel/AMD. Хруст - похоже какое-то временное промежуточное решение. А Винду по-тихоньку отвязывают от x86-64.
	Ответить | Правка | Наверх | Cообщить модератору

	125. Скрыто модератором	+1 +/–
	Сообщение от morphe (?), 05-Мрт-25, 09:15
	Откуда берутся сектанты верующие в святой эльбрус/байкал? И как это должно помогать от переполнений буфера, когда у тебя юзерспейс аллокатор выделяет память большими кусками, и софт/железо по итогу никак не отличает одну аллокацию от другой?
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	136. Скрыто модератором	+1 +/–
	Сообщение от _erthink (?), 05-Мрт-25, 09:48
	"Байкалы" это действительно просто mips/arm/risc5, где железо ничего не отличает. А вот на "святых эльбрусах" есть теги в памяти (лежат вместе с битами ecc) и 128-битные указатели (включают размер буфера на который они указывают), а железо всё это проверяет. Поэтому в безопасном режиме на e2k буфер действительно переполнить нельзя.
	Ответить | Правка | Наверх | Cообщить модератору

	152. Скрыто модератором	+1 +/–
	Сообщение от morphe (?), 05-Мрт-25, 10:31
	> Поэтому в безопасном режиме Ключевое слово. А теперь вопрос сколько програм в этом режиме собираются и работают (Ах, да: https://github.com/mbarashkov/e2k-protected-mode-patches/blo...), и какой оверхед в рантайме за собой несёт (Я лишь знаю что без protected mode указатели в 2 раза меньше) И зачем нести этот оверхед, если с Rust у тебя все эти проверки могут пройти на этапе компиляции/явным образом и гарантированно в рантайме, при этом без привязки к железу? Я не знаю как оно у эльбруса, однако я знаю что тот же CHERI не особо полезен с Rust, это железо было специально заточено для языков которые не способны сами спасти от дыр. И даже там в безопасном софте у тебя зачастую дублируются проверки в железе и в софте, потому что в большинстве случаев тебе нужно самому обработать потенциальное переполнение, а не делать чтобы софт слепо падал. Компиляторы вроде Rust способны свою проверку границ убрать если могут доказать что выход за пределы невозможен, а вот в железе эта проверка всегда будет, пускай со спекуляцией она и может быть дешевле.
	Ответить | Правка | Наверх | Cообщить модератору

	163. Скрыто модератором	–1 +/–
	Сообщение от Аноним (73), 05-Мрт-25, 11:19
	> А теперь вопрос сколько програм в этом режиме собираются и работают смешной какой - а сколько на раст написано? > И зачем нести этот оверхед, если с Rust у тебя все эти проверки могут пройти на этапе компиляции/явным образом и гарантированно в рантайме, при этом без привязки к железу? затем чтобы не переписывать то что работает а просто пересобрать. Проверки в рантайме всё равно нужны потому что железо ты проверить не сможешь, или ты уже отключил MMU и IOMMU на своих серверах - с растом же безопасно. В отличии от раста аппаратные защиты не снижают производительность.
	Ответить | Правка | Наверх | Cообщить модератору

	261. Скрыто модератором	+1 +/–
	Сообщение от _erthink (?), 06-Мрт-25, 13:04
	CHERI во многом похож на безопасный режим Эльбруса. Но в e2k он появился в "железе" на ~20 лет раньше первых черновиков спеки CHERI. Кроме этого, в e2k было несколько редакций, включая поддержку private/public из C++ и т.п. Основная проблема как безопасного режима Эльбруса, так и CHERI, не в оверхеде, а в том что 99% софта нужно переписывать (имеется в виду что смотрим только на релевантный код, а не на питон/bash/java и т.п). В этом, кстати, существенная часть мифа riscv -- на деле вы получаете что-то одно: простоту и дешевизну, производительность, безопасность, но никогда вместе. Особо забавно что часть "экспертов" подразумевают/считают/утверждают, что с CHERI будет также быстро как и без, что будет жрать почти столько-же питания, не сильно дороже, а еще и софт сразу будет совместим ;) > И зачем нести этот оверхед, если... Все всегда будут хотеть снизить накладные расходы и сэкономить на безопасности. Там где безопасность желательна, но не обязательна, вполне логично не только по-полной идти во все тяжкие со спекулятивным выполнением, но даже выбрасывать защиту памяти. Это действительно логично, ведь если у вас весь софт доверенный/отлаженный/проверенный и на условном java/rust, то оставшимися рисками можно пренебречь (например в играх и т.п). А вот там где требуются некие гарантии без аппаратной защиты не обойтись -- там как накладные расходы, так и стоимость соответствующей аппаратуры, принимаются как неизбежное. Это просто ближе большинству сценариев в реальном мире, в том числе потому что невозможно всё нужное/используемое переписать на условных rust/java в разумные сроки. Суммарно рациональнее иметь язык обеспечивающий максимум статических проверок при компиляции и эффективно пользоваться аппаратурой для контроля в runtime, при этом аппаратура может быть как простой, так и обеспечивающей принудительную безопасность. Проблема как языка С, так и "сишного" кода, особенно унаследованного, не в том что он подвержен общеизвестным типам багов, а в том что не позволяет задействовать контролирующую/проверяющую аппаратуру, т.е не совместим ни с безопасным режимом e2k, ни с CHERI. Кстати, поэтому C также является одной из проблем отечественных Эльбрусов. Если помечтать что Linux был-бы написан на условном Rust, то Эльбрусы бы целиком могли работать в безопасном режиме (который тогда можно было-бы допилить/оптимизировать в нужную сторону), а в компиляторе не было-бы EDG-отравы. Что касается Rust, то при всем моём уважении, там есть что улучшить/допеределать. Нужно что-то более удобное для объектных подходов и менее птичье по набору соседствующих букв.
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	262. Скрыто модератором	+1 +/–
	Сообщение от _erthink (?), 06-Мрт-25, 13:05
	CHERI во многом похож на безопасный режим Эльбруса. Но в e2k он появился в "железе" на ~20 лет раньше первых черновиков спеки CHERI. Кроме этого, в e2k было несколько редакций, включая поддержку private/public из C++ и т.п. Основная проблема как безопасного режима Эльбруса, так и CHERI, не в оверхеде, а в том что 99% софта нужно переписывать (имеется в виду что смотрим только на релевантный код, а не на питон/bash/java и т.п). В этом, кстати, существенная часть мифа riscv -- на деле вы получаете что-то одно: простоту и дешевизну, производительность, безопасность, но никогда вместе. Особо забавно что часть "экспертов" подразумевают/считают/утверждают, что с CHERI будет также быстро как и без, что будет жрать почти столько-же питания, не сильно дороже, а еще и софт сразу будет совместим ;) > И зачем нести этот оверхед, если... Все всегда будут хотеть снизить накладные расходы и сэкономить на безопасности. Там где безопасность желательна, но не обязательна, вполне логично не только по-полной идти во все тяжкие со спекулятивным выполнением, но даже выбрасывать защиту памяти. Это действительно логично, ведь если у вас весь софт доверенный/отлаженный/проверенный и на условном java/rust, то оставшимися рисками можно пренебречь (например в играх и т.п). А вот там где требуются некие гарантии без аппаратной защиты не обойтись -- там как накладные расходы, так и стоимость соответствующей аппаратуры, принимаются как неизбежное. Это просто ближе большинству сценариев в реальном мире, в том числе потому что невозможно всё нужное/используемое переписать на условных rust/java в разумные сроки. Суммарно рациональнее иметь язык обеспечивающий максимум статических проверок при компиляции и эффективно пользоваться аппаратурой для контроля в runtime, при этом аппаратура может быть как простой, так и обеспечивающей принудительную безопасность. Проблема как языка С, так и "сишного" кода, особенно унаследованного, не в том что он подвержен общеизвестным типам багов, а в том что не позволяет задействовать контролирующую/проверяющую аппаратуру, т.е не совместим ни с безопасным режимом e2k, ни с CHERI. Кстати, поэтому C также является одной из проблем отечественных Эльбрусов. Если помечтать что Linux был-бы написан на условном Rust, то Эльбрусы бы целиком могли работать в безопасном режиме (который тогда можно было-бы допилить/оптимизировать в нужную сторону), а в компиляторе не было-бы EDG-отравы. Что касается Rust, то при всем моём уважении, там есть что улучшить/допеределать. Нужно что-то более удобное для объектных подходов и менее птичье по набору соседствующих букв.
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	229. Скрыто модератором	+/–
	Сообщение от maximnik0 (?), 05-Мрт-25, 22:30
	> "Байкалы" это действительно просто mips/arm/risc5, где железо ничего не отличает. RISC-V MTE https://github.com/riscv/riscv-memory-tagging
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	268. Скрыто модератором	+/–
	Сообщение от _erthink (?), 06-Мрт-25, 14:35
	В 2023 году "Байкал Электроникс" обещали (https://russianelectronics.ru/2023-10-20-baikal-electronics/...) показать ЦПУ с ядром RISC-V в прошлом году. Обещанного ждут три года, но могу поспорить то MTE там не будет, даже не пахнет в перспективе. Делать ЦПУ уровня микроконтроллера за год совсем не сложно, даже не понятно почему не вышло. Скорее всего у Байкала проблемы просто с тиражом, ибо отечественные фабрики накрыл медным тазом еще аж Чубайс. А вот ЦПУ конкурирующий хотя-бы с ТВГИ.431281.023 придется дизайнить чуть подольше, глядишь к 2028 испекут (с отставанием  в 10 лет от Эльбрусов). Но с учетом того что патенты на многие ключевые моменты всё еще действуют и то что Байкал и Ядро ранее занимались лего-дизайном, а не реальной разработкой ядер, то вряд-ли получиться что-то конкурирующее c T-Head. Но кто я такой чтобы меня слушать, не то чтобы верить. Ну и IMHO, RISC-V это стеклянные бусы для папуасов, но очень удобно для попила/осваивания бюджета на НИОКР. Как говорится, правильный попил -- дело благородное (https://www.kommersant.ru/doc/7552143) ;) Государственных денег я бы не давал, а предложил-бы господам выпустить акции/облигации для желающих встрять и/или неистово инженерить. Но опять-таки, кто я такой чтобы меня слушать, не то чтобы верить. Жаль что второй раз наступаем на грабли EC-ЭВМ, что один разу уже похоронило отечественную отрасль на полвека.
	Ответить | Правка | Наверх | Cообщить модератору

	275. Скрыто модератором	+/–
	Сообщение от maximnik0 (?), 06-Мрт-25, 20:59
	> и IMHO, RISC-V это стеклянные бусы для папуасов, но очень удобно для попила/осваивания бюджета на Да практически везде так - где импортозамещение.Вон монитор тому пример- прилепили микросхему которая нахрен не нужна. Беда в том что количество все решает _ а у нас нет такого рынка для сбыта, соответственно бусы будут дороже импортных аналогов в любом раскладе.А главное нет стимула для развития - вон снимут санкции и опять принемся всё закупать со страшной силой.
	Ответить | Правка | Наверх | Cообщить модератору

	282. Скрыто модератором	+/–
	Сообщение от n00by (ok), 07-Мрт-25, 11:51
	> Беда в том что количество все решает _ а у нас нет > такого рынка для сбыта "Нет рынка" означает "рынок захвачен". То есть, с точки зрения экономики, идёт война (и free RISC-V -- обычный демпинг) и следует говорить "как вернуть утраченные позиций?" > соответственно бусы будут дороже импортных аналогов в > любом раскладе.А главное нет стимула для развития - вон снимут санкции > и опять принемся всё закупать со страшной силой. Расклад сейчас такой, что инвесторы говорят "нет людей". Людей нет, поскольку одни уехали, а другие собирают из кубиков Лего, не шибко напрягая извилину. Получается замкнутый круг.
	Ответить | Правка | Наверх | Cообщить модератору

	142. Скрыто модератором	+/–
	Сообщение от maximnik0 (?), 05-Мрт-25, 10:03
	>И как это должно помогать от переполнений буфера, когда у тебя юзерспейс аллокатор Прочли бы учебник-вопросов не возникло бы. Cтр 98 Архитектура «Эльбрус» защищает контекст программного модуля, образо- ванный объектами, которые допускается в нем использовать согласно пра- вилам языка программирования. Это делается путем организации доступа к низкоуровневому представлению объекта в памяти или регистрах через «проходную» его дескриптора — служебного слова, содержащего ссылку и информацию об объекте, соответствующую его типу. Доступ возможен только через дескриптор. Аппаратные операции создания и использования дескрипторов специализированы таким образом, что не оставляют возмож- ности непосредственного воздействия на объект. Scip Ни длина, ни тип числовых данных архитектурно не различимы. В отличие от числовых данных, нечисловые данные строго типизируются. Прежде всего гарантируется целостность составных форматов (двойное слово и квадро), что предполагает следующее: все фрагменты должны иметь тип, соответствующий формату; Scip В общем  в дискрипторе размер и тип буфера.Попытка записи за пределы буфера-Гитлер капут,срабатывание защиты.
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	116. Скрыто модератором	+2 +/–
	Сообщение от Аноним (116), 05-Мрт-25, 09:01
	Никто почему-то не вспоминает о том, что грибы это ПАРАЗИТИРУЮЩИЙ организм
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	166. Скрыто модератором	+1 +/–
	Сообщение от Аноним (166), 05-Мрт-25, 11:34
	>Удивительно, но хейтерочки не знают, что Rust назван в честь очень живучих грибков. Но то, что автор перед началом его "проектирования" наелся грибочков, это точно.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	27. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 04-Мрт-25, 22:42
	> Название Rust говорит само за себя - ржавление. Все намного хуже! Цитата с википедии про Rust: Rust began as a personal project in 2006 by Mozilla employee Graydon Hoare.[16] Hoare has stated that Rust was named for the group of fungi that are "over-engineered for survival". Т.е. это инфекционное паразитическое заболевание, во как!
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	98. Скрыто модератором	–2 +/–
	Сообщение от n00by (ok), 05-Мрт-25, 07:36
	Любопытно, откуда автор узнал о тех грибах? Например, мне рассказывали, как в европах в голодные годы народ вкушал заражённый спорыньей хлеб, после чего принимался бурлить и устраивать революции.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–3 +/–
	Сообщение от Аноним (8), 04-Мрт-25, 22:13
	> а на раст перейти нельзя из-за Из-за отсутствия lts версий rustc. И не надо заливать про эндианы. Они фиксируют не компилятор, а язык.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	18. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от НяшМяш (ok), 04-Мрт-25, 22:28
	За lts можно брать версию, которую в дебиане или сентоси заплесневели.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (-), 04-Мрт-25, 22:43
	> За lts можно брать версию, которую в дебиане или сентоси заплесневели. При этом всегда найдется какой-нибудь bcachefs'ный тул который им не компилится. Не могут хайпующие хипстики - в LTS. Не их это.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Карлос Сношайтилис (ok), 04-Мрт-25, 23:48
	То что у тебя bcachefs не компилируется из-за того что сишники не могут в lts это печально, но причём тут Раст?
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от morphe (?), 05-Мрт-25, 01:00
	У bcachefs утилиты для управления на Rust написаны, и они требуют последнюю версию компилятора. Что однако любому сишному пакету мешает зависеть от более новых версий других пакетов - история умалчивает.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (-), 06-Мрт-25, 10:51
	> То что у тебя bcachefs не компилируется из-за того что сишники не > могут в lts это печально, но причём тут Раст? При том что не компилится у этого этого добра - кусок на хрусте, системным тулчейном хруста из дебиана. За что оно и вылетело из Stable версии, если кто пропустил новости. Так что как видите точка зрения - подперта конкретными фактами по части хрустиков.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	64. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от morphe (?), 05-Мрт-25, 00:59
	Т.е ты хочешь брать не-LTS пакет, и собирать его LTS компилятором? Гнилому компилятору гнилые пакеты, у тебя проблемы ещё с любыми другими пакетами могут быть аналогичные.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	180. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–2 +/–
	Сообщение от Аноним (180), 05-Мрт-25, 13:01
	> Гнилому компилятору гнилые пакеты С чего вдруг? Потому что ты так сказал? Посмотри какие версии gcc новое ядро linux требует. Собирать на всех поддерживаемых дистрибутивах установленными в дистрибутив компиляторами - базовое требование для системных проектов. То что система встройки rust в ядро всегда требует последнюю версию компилятора - это огромная проблема! И она не решаема.
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от morphe (?), 07-Мрт-25, 19:44
	> То что система встройки rust в ядро всегда требует последнюю версию компилятора > - это огромная проблема! И она не решаема. Утилиты bcachefs не могут требовать более новую версию Rust чем существовала на момент их (утилит) выхода. То что мейнтейнеры решают выборочно обновлять пакеты - это огромная проблема! И она решаема, нужно только захотеть.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (250), 06-Мрт-25, 11:41
	> Т.е ты хочешь брать не-LTS пакет, и собирать его LTS компилятором? > Гнилому компилятору гнилые пакеты, у тебя проблемы ещё с любыми другими пакетами > могут быть аналогичные. В итоге bcachefs'овские тулсы из дебиана просто выперли с аргументом "их хруст не билдуется системным тулчейном хруста". Все что надо знать о хрусте vs LTS, в общем то. И да, C++ таким маразом не страдает.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	49. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (49), 05-Мрт-25, 00:02
	Нужно эквивалентное поведение программы, а не lts и подобные костыли.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	9. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
	Сообщение от Ivan_83 (ok), 04-Мрт-25, 22:13
	Минусы/плюсы ничего не значат. Не проблема это когда там чото с памятью не то. Проблема это когда совсем кода нет, или когда нужного функционала нет. А когда код есть, но бывает падает - это уже то с чем можно жить, но конечно хочется совсем без этого. Насчёт легаси кода - забавный подход с навешиванием ярлыков. Ну типа щас уберём резко весь "легаси" на С и крестах - и что останется? - НИЧЕГО. Даже хруст не чем будет собрать и где запускать. Так что это не легаси а меинстрим получается по факту.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	43. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Карлос Сношайтилис (ok), 04-Мрт-25, 23:52
	> но бывает падает - это уже то с чем можно жить Жить, когда падает, можно. С современным подходом к отказоустойчивости это как раз не проблема. Проблема когда не падает, а даёт доступ к памяти из-за уязвимости.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (60), 05-Мрт-25, 00:31
	И что тебе уже сломали или украли? Не надо называть проблемой то, что существует только на бумажке.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 01:00
	Лично меня, за последние несколько лет, – нет, не ломали (или я об этом не знаю, хех). Сервера с которыми я имею дела, прямо или опосредованно, – да. Начиная от дешёвых хостингов, которые ломают через дыры в кривых CMS, и заканчивая серверами в зоне business critical и выше, где атаки уже точечно-целевые. Было бы оно на бумаге, все бы на этот Раст и безопасность чихать хотели бы.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от bOOster (ok), 05-Мрт-25, 09:22
	> Лично меня, за последние несколько лет, – нет, не ломали (или я > об этом не знаю, хех). > Сервера с которыми я имею дела, прямо или опосредованно, – да. Начиная > от дешёвых хостингов, которые ломают через дыры в кривых CMS, и > заканчивая серверами в зоне business critical и выше, где атаки уже > точечно-целевые. > Было бы оно на бумаге, все бы на этот Раст и безопасность > чихать хотели бы. Обычно 99% дыр прикрыты огромным количеством софта по безопасности. Всякие нюхачи типа SNORT, антивирусы, систем блокировки трафика по портам, по контексту и т.д. Если ты идешь на самый дешевый сервис с какого перепугу ты ищешь в этом виноватого? За защиту своей системы ты сам несешь ответственность. Теперь про CMS и их взломы. Это будущее Ржи.. Факты взлома CMS - это яркий показатель что даже использование языков которые ВООБЩЕ С ПАМЯТЬЮ не работают и т.д. не гарантирует тебе абсолютно никакой безопасности.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (49), 05-Мрт-25, 05:37
	У моего клиента кучу всего переломали. Use-after-free в сишном демоне, рут шелл, ддос-ферма. Благо мониторинг работает, заметили что начали ноды из сети пропадать и исходящий трафик трендить в лимит, обломали кому-то праздник. Но трафик ещё полбеды, с провайдером всегда можно договориться. Месяц разгребали получившийся в результате бардак, кого-то из отпуска вызвали, каким-то кастомерам сроки сорвали, и у них что-то следом посыпалось, в целом нервная атмосфера — вот это реально дорого вышло. То, что вас весь бизнес — это лендинг на народе.ру и сеточка 192.168.0.0/24 не значит, что у всех так.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	93. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–2 +/–
	Сообщение от Ivan_83 (ok), 05-Мрт-25, 06:26
	Бизнесс это про риск манагемент. В остальном нынче легко софт запереть так чтобы оно ничего не могло сделать кроме того для чего создано.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (118), 05-Мрт-25, 09:02
	>>Use-after-free в сишном демоне расскажите как вы это определили
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	238. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (49), 06-Мрт-25, 06:33
	Реплей трафика и пару часов в gdb. Спроси лучше как атакующие это определили, это куда интереснее.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от bOOster (ok), 05-Мрт-25, 09:24
	> У моего клиента кучу всего переломали. Use-after-free в сишном демоне, рут шелл, > ддос-ферма. Благо мониторинг работает, заметили что начали ноды из сети пропадать > и исходящий трафик трендить в лимит, обломали кому-то праздник. Но трафик > ещё полбеды, с провайдером всегда можно договориться. Месяц разгребали получившийся в > результате бардак, кого-то из отпуска вызвали, каким-то кастомерам сроки сорвали, и > у них что-то следом посыпалось, в целом нервная атмосфера — вот > это реально дорого вышло. То, что вас весь бизнес — это > лендинг на народе.ру и сеточка 192.168.0.0/24 не значит, что у всех > так. Дай догадаюсь - А да, руководство решило что компания слишком много платит профессионалу/ам..
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	239. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (49), 06-Мрт-25, 06:51
	> Дай догадаюсь - А да, руководство решило что компания слишком много платит профессионалу/ам.. Нет, с чего ты взял? Обычная компания — свой продукт, медианные зарплаты, соцпакет, wfh.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (73), 05-Мрт-25, 01:49
	> Жить, когда падает, можно. С современным подходом к отказоустойчивости это как раз не проблема. тебе там выше написали про аппаратную защиту памяти но ты прочитать не сумел, а с ней ничего переписывать не надо
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	92. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Ivan_83 (ok), 05-Мрт-25, 06:24
	Это не так часто становилось реальной проблемой.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	35. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (35), 04-Мрт-25, 22:56
	Вы знаете, дорогие друзья по растосрачу, я пришёл к выводу что секрет успеха сижки в том, что там правильно поставлен приоритет в отличие от плюсов и прочих брейнфаков. Поясню: брейнфаки приоритетят безопасность, мол а как же так, а что если ты не туда присунешь переменную, или там вообще за границу уедешь. Это как бы факт. Их это волнует, и вот они городят свой забор с защитой от всего что попало. Сижка же говорит: да и хрен с ним. И фокусируется на том чтобы быть простой и прозрачной без лишних вывертов. Результат: весь код на сижке и с багами. Брейнфакеры крякают, но мы то знаем
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	38. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–2 +/–
	Сообщение от Аноним (38), 04-Мрт-25, 23:08
	> я пришёл к выводу что секрет успеха сижки в том, что там правильно поставлен приоритет Его сделали таким, что даже умственно отсталые могут как-то писать? > Сижка же говорит: да и хрен с ним. Логично. Если язык овняный, то и код должен соответствовать. > быть простой и прозрачной без лишних вывертов. Хахаха, такое мог сказать только тот, кто не читал "стандарт" (тот самый, от котого плевался сам создатель языка) > Результат: весь код на сижке и с багами. Сишку выкинули уже из практически всех ниш. Остались самые копролитные легаси проекты. > Брейнфакеры крякают, но мы то знаем Знаете что? Что пришете овнокод? Ну так это все знают)) Что сейчас народу важна корректность кода? Ну так сейчас всех дыряшечников начинают потихоньку уринированными тряпками гонять. Почему уже 2 разных(!!) проекта как заставить дидовый кодище работать хоть немного лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (35), 05-Мрт-25, 00:21
	Продолжай убеждать себя
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (35), 05-Мрт-25, 00:29
	Вообще знаешь что, пашел нахрен с бубунты тогда если у тебя не работает
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	45. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Карлос Сношайтилис (ok), 04-Мрт-25, 23:59
	> Поясню: брейнфаки приоритетят безопасность, мол а как же так, а что если ты не туда присунешь переменную, или там вообще за границу уедешь. Это как бы факт. Их это волнует, и вот они городят свой забор с защитой от всего что попало. Ты написал все правильно, только переменные перепутал (что не удивительно). Растоманы не беспокоются о безопасности, им это даёт язык, можно писать код, не задумываясь о границах итераторов и прочей мелочи, как в примере из статьи. Язык кривой код не скомпилирует. А вот сишники и их братья плюсовики вынуждены думать через строчку: стрельнёт / не стрельнёт. Но стреляет у всех, даже у профи, потому что мы человеки и быть всегда на сто процентов в фокусе невозможно.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	96. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Ю.Т. (?), 05-Мрт-25, 06:41
	Это называется оптимальное решение. Хотя не следует забывать, что могут измениться и сам критерий оптимальности, и выставляемые ограничения. Для своего времени Си оказался хорош. Может ли он продолжать оставаться хорош? Вопрос. Ведь меняется и структура рынка, а тут уже могут включаться и вовсе "нетехнические" параметры. ЗЫ Жаль, что создателя Раста когда-то перл укусил.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	145. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от BeLord (ok), 05-Мрт-25, 10:17
	Секрет в том, что дефективные манагеры не шарят в разработке, если код спроектирован правильно, если гвоздями прибиты требования безопасности и стиля написания кода -  что С, что Rust даст нормальный результат. А вот, если мозг отключен, тестирования нет и код записки сатаны, тогда результат будет дерьмовый, что на С, что на Rust.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	48. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (48), 05-Мрт-25, 00:01
	Значение идиомы "бородатая шутка" почти забыто, я так посмотрю... Ничего не имею против ржавого, но эти растофанатикотролли, 99% которых за всю жизнь и строчки кода не написали "доставляют" и вызывают желание только закрыть тред предварительно пожелав сажи во все поля.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	83. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (83), 05-Мрт-25, 04:47
	Напомню, 10 лет назад я писал что проще в c++ добавить гарантии. На что растоманы отвечали что это невозможно. Теперь растоманы в очередной раз переобулись. Нагрянуло.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	137. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (137), 05-Мрт-25, 09:51
	> а на раст перейти нельзя из-за кучи легаси кода и лени учить новый язык. Ну а также можете предложить ООПный язык как плюсы, только с этой безопасной работой с памятью? Rust скажем так не совсем таков.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	210. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (210), 05-Мрт-25, 16:21
	Эта "кучка легаси кода" всего то 70~98% из всего х86 кода, сущая мелочь ага)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+5 +/–
Сообщение от SL_RU (?), 04-Мрт-25, 22:09
Для начала пусть сделают правило чтобы нельзя было значение optional использовать без проверки
Ответить | Правка | Наверх | Cообщить модератору

	56. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 00:21
	Да какой optional, окстись! Тут на одних только указателях два новых стандарта наваять можно. Точнее – нужно.
	Ответить | Правка | Наверх | Cообщить модератору

5. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+14 +/–
Сообщение от Аноним (8), 04-Мрт-25, 22:11
То есть вся ценность rust свелась к одному заголовочному файлу для C++? Или я что-то не так понял?
Ответить | Правка | Наверх | Cообщить модератору

	10. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Bottle (?), 04-Мрт-25, 22:17
	Всё правильно понял. А ещё любители ржавчины почему-то думают, что если весь код завернуть в unsafe, этот ансейф будет безопаснее сишного. Если язык позволяет что-то сломать, это обязательно произойдёт. Поэтому Rust небезопасен by design, потому что позволяет небезопасные вещи. Подобно Джаве, которая позволяет делать небезопасные и некорректные вещи (линковка с C/C++ через JNI, платформозависимая арифметика), язык Rust со временем будет также признан "недостаточно безопасным", а затем придумают ещё один язык, в этот раз точно супербезопасный, мамой клянусь! И будут на него переписывать небезопасные программы на небезопасном Расте.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+6 +/–
	Сообщение от Аноним (38), 04-Мрт-25, 22:54
	> А ещё любители ржавчины почему-то думают, что если весь код завернуть в unsafe, этот ансейф будет безопаснее сишного. У ржавых просто сделано по человечески "вот мускорка, мы туда складываем всякие стремные штуки. А в остальном доме мусорить плохо". А у С/С++ - просто овно размазано ровным слоем по всей квартире. > Если язык позволяет что-то сломать, это обязательно произойдёт. Надеюсь что ты живешь в многоэтажке с лестницами без перил, ездишь на авто без подушек безопасности и используешь только неизолированные провода)) > Поэтому Rust небезопасен by design, потому что позволяет небезопасные вещи. Твое мнение очень важно для нас. Пойду поем. > язык Rust со временем будет также признан "недостаточно безопасным", а затем придумают ещё один язык, Было бы неплохо, лет так через 20.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от dl (??), 05-Мрт-25, 13:44
	вы ещё забыли про динозвров, метеориты, извощиков разных типов и может ещё чтото... вот честно, надоели все ваши эти аналогии
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от анонимусс (-), 05-Мрт-25, 13:51
	> вы ещё забыли про динозвров, метеориты, извощиков разных типов и может ещё чтото... зато не забыл про CVE и новости раз в пару недель "в дырявом коде нашли пачку уязвимостей" > вот честно, надоели все ваши эти аналогии не нравится - не читайте)
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от qwe (??), 08-Мрт-25, 02:35
	> Надеюсь что ты живешь в многоэтажке с лестницами без перил, ездишь на авто без подушек безопасности и используешь только неизолированные провода)) Раст не создает перила, он лишь не позволяет их пересекать. То есть растоманы и плюсовики ходят по одним и тем же лестницам, разница лишь в том, что первым администрация здания доверяет меньше, чем вторым.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	14. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–6 +/–
	Сообщение от НяшМяш (ok), 04-Мрт-25, 22:26
	Ага, заголовочный файл включи, команды компилятору передай, С++20 перейди. Сколько дидов этим будет реально заморачиваться? А в расте это есть из коробки и по-умолчанию - тем он и хорош.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	20. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
	Сообщение от Аноним (8), 04-Мрт-25, 22:29
	А диды будут пользоваться растом? Так пишите будто бы да. А молодняк будет обязательно соблюдать все требования раста? Или всё-таки будет вилять и пытаться обойти ограничения? Это пока растом интересуются более-менее понимающие люди, код нормальный. А как пойдёт в массы (если), то массы будут писать овнокод с обходом ограничений раста, лишь бы запускалось.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (-), 04-Мрт-25, 22:31
	> о массы будут писать овнокод с обходом ограничений раста, лишь бы запускалось. Фишка в том, что обход ограничений виден за версту! И ты можешь просто прогрепать сколько строк внутри ансефа.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (8), 04-Мрт-25, 22:33
	Жду спортивное программирование на расте на голом unsafe, без единого safe.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 00:26
	> А молодняк будет обязательно соблюдать все требования раста? Или всё-таки будет вилять и пытаться обойти ограничения? Сильно не повиляешь – даже ансейф не делает из раста cишку. А в сейф и того подавно. А за ансейф, не к месту, на код ревью, по сусалам надают – вредные привычки надо искоренять.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	147. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (147), 05-Мрт-25, 10:20
	> код ревью Чел, оно далеко не везде есть. Даже в крупных компаниях.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Ю.Т. (?), 05-Мрт-25, 06:45
	Именно этот момент и выпадает из пропаганды Раста (слово пропаганда без осуждения, пусть будет промоущен). Можно придумать сколь угодно совершенный формальный язык, и все равно с этой стороны интерфейса с ним будет работать несовершенный (по определению) писатель на этом языке.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	100. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (99), 05-Мрт-25, 07:44
	молодняк не будет пользоваться растом из-за сложности вхождения. им подавай питон или джаваскрипт
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	240. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Молодой Смузихлёб (?), 06-Мрт-25, 06:54
	Дважаскрипт уж точно лучше раста, но в ядро Линукс его не пропихивают!
	Ответить | Правка | Наверх | Cообщить модератору

	277. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Прохожий (??), 07-Мрт-25, 02:39
	> Дважаскрипт уж точно лучше раста Уж точно - нет, не лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от User (??), 05-Мрт-25, 10:58
	Ну вообще - там, где надо (хинт - не в opensouce, этим и впрямь покласть) на уровне проекта вполне себе энфорсится.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	15. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
	Сообщение от Аноним (-), 04-Мрт-25, 22:26
	> То есть вся ценность rust свелась к одному заголовочному файлу для C++? Нет. "реализована на базе сильных и слабых ссылок" Т.е. то что в расте реализовано в компайлтайме, в плюсах будет проверяться в рантайме. С соответствующими накладными расходами на исполнения.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	26. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
	Сообщение от Аноним (26), 04-Мрт-25, 22:40
	Нет. Тут другая модель управления память. Не как в Rust, когда компилятор отслеживает единственного владельца сильной за счет "заимствования", а стандартный shared_ptr, которых может быть несколько. Вот эти "несколько" и отслеживаются плагином во время компиляции, чтобы не было циклических и зависших ссылок. А в рантайме проверяется только счетчик владений в shared_ptr с атомарными инкрементами и декрементами.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (-), 04-Мрт-25, 22:52
	> А в рантайме проверяется только счетчик владений в shared_ptr > с атомарными инкрементами и декрементами. Этого вполне достаточно для замедления программы :) Гугел и не только уже экспериментировали со всякими miracle_ptr и оно реально тормозило.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 00:07
	Знаменитое zero-cost из C++: оно как бы zero, но не совсем. — У нас есть классы и оно zero-cost! (vtable не считается) — У нас есть умные указатели и они zero-cost! (игнорируем счётчик ссылок) — А как получить настоящий zero-cost? — Это к С, мальчик. Иди, не мешай дядям.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	91. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
	Сообщение от Аноним (91), 05-Мрт-25, 06:08
	TANSTAAFL. Zero-cost не бывает в принципе. Да, ваш любимый раст - он в 2 раза медленнее, чем C++.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 07:49
	> Да, ваш любимый раст - он в 2 раза медленнее, чем C++ Ага, раст делает проверки и оптимизации в компайл тайме, а С++ – в рантайме, поэтому С++ быстрее. Л – логика.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от мяв (?), 05-Мрт-25, 10:07
	вообще-то, например, при получении, условно, элементов массива в while-цикле с инкрементом, растц вполне себе рантайм проверку бахнет. и код будет медленне такого же на С, до момента, пока в С-версии не добавят проверку.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (41), 05-Мрт-25, 15:55
	> и код будет медленне такого же на С, до момента, пока в С-версии не добавят проверку. Теорема Чёрча — Россера
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 09:50
	Как вынести условие цикла за*) цикл? *) Для других, шибко умных анонимов: за оператор while, а не тело.
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (41), 06-Мрт-25, 15:02
	> Как вынести условие цикла за*) цикл? кхммм, как это условие выхода из цикла вынести за цикл, переформулируйте или вы имеете ввиду goto-акробатику?
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 07-Мрт-25, 11:54
	>> Как вынести условие цикла за*) цикл? > кхммм, как это условие выхода из цикла вынести за цикл, переформулируйте или > вы имеете ввиду goto-акробатику? Я имею ввиду, что задачу можно решить в частных случаях, не для всех while.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 09:54
	Если это всё померить, то окажется, что проверка предсказывается и не сказывается на производительности.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	249. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (249), 06-Мрт-25, 11:28
	> вообще-то, например, при получении, условно, элементов массива в while-цикле с инкрементом, растц вполне себе рантайм проверку бахнет. > и код будет медленне такого же на С, до момента, пока в С-версии не добавят проверку. Ну да, всего делов-то - вместо использования итератора удалять гланды^W^W "написать как в сишке" и вот тогда ...
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	278. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Прохожий (??), 07-Мрт-25, 02:43
	Есть обходные решения для этого: https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-ru...
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	198. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от 111 (??), 05-Мрт-25, 15:06
	> Да, ваш любимый раст - он в 2 раза медленнее, чем C++. Где пруфы?
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	225. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (249), 05-Мрт-25, 21:17
	>> Да, ваш любимый раст - он в 2 раза медленнее, чем C++. > Где пруфы? Вот: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... просто нужно брать правильные программы для сравнения! А если  по потреблению памяти(больше == лучше), то вообще любая плюсанутая вариация уделывает этот ваш сраст в 2-5 раз!
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (-), 05-Мрт-25, 21:24
	> Вот: > https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Первый же пример fannkuch-redux                 secs     cpu secs     mem * C++ g++ #6    3.33     13.12         5,800 * Rust #6    3.81     15.06         3,985      > просто нужно брать правильные программы для сравнения! Ага) Ты прям выбрал, так выбрал) > А если  по потреблению памяти(больше == лучше), то вообще любая плюсанутая  вариация уделывает этот ваш сраст в 2-5 раз! Ты имел про то что оно жрет больше?
	Ответить | Правка | Наверх | Cообщить модератору

	231. Скрыто модератором	+/–
	Сообщение от Аноним (249), 05-Мрт-25, 23:06
	> он в 2 раза медленнее > * C++ g++ #6    3.33  13.12  5,800 > * Rust #6 3.81  15.06   3,985 >> просто нужно брать правильные программы для сравнения! > Ага) Ты прям выбрал, так выбрал) > 3.33 > 3.81 > 2 раза Ну ты прям метаном^W всем показал, так показал! Че там кстати с другими тестами? * Rust #7     0.78     2.00     157,442      C++ g++ #6    1.14     2.25     285,639      ==== * Rust #7     0.78     2.00     157,442      C++ g++ #6     1.14     2.25     285,639      "нещитаица" или "этодругое"?
	Ответить | Правка | Наверх | Cообщить модератору

	233. Скрыто модератором	+/–
	Сообщение от Аноним (-), 05-Мрт-25, 23:17
	> Ну ты прям метаном^W всем показал, так показал! Продолжаешь обделываться? > Че там кстати с другими тестами? > * Rust #7  0.78  2.00  157,442 > C++ g++ #6 1.14  2.25  285,639 Давай разделим 1.14 на 0.78 и получим... два не получаем. Все фанатики такие убого безграмотные или ты просто такой униКал? > "нещитаица" или "этодругое"? Что другое? Ты тут пуукнул про "в 2 раза медленнее", потом выпукал "в 2-5 раз". А теперь обделался и пытаешь слиться.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Cooler (??), 05-Мрт-25, 09:14
	std::unique_ptr<…> - zero-cost. struct{…}, class{…} без виртуальных функций - zero-cost. А там где нужны виртуальные функции, ты и на С не сможешь без индирект-call.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	230. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 05-Мрт-25, 23:04
	>  std::unique_ptr<…> - zero-cost. Нет, ABI запрещает передавать его через регистры, что не даёт ему быть zero-cost. При добавлении нестандартного [[clang::trivial_abi]] "Google has measured performance improvements of up to 1.6% on some large server macrobenchmarks, and a small reduction in binary sizes" - https://libcxx.llvm.org/DesignDocs/UniquePtrTrivialAbi.html
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 10:06
	>>  std::unique_ptr<…> - zero-cost. > Нет, ABI запрещает передавать его через регистры, что не даёт ему быть > zero-cost. Не вижу запрета 3.2.3 Parameter Passing After the argument values have been computed, they are placed either in regis- ters or pushed on the stack. The way how values are passed is described in the following sections. Definitions We first define a number of classes to classify arguments. The classes are corresponding to AMD64 register classes and defined as: INTEGER This class consists of integral types that fit into one of the general purpose registers. ... NO_CLASS This class is used as initializer in the algorithms. It will be used for padding and empty structures and unions. ... The classification of aggregate (structures and arrays) and union types works as follows: 1. If the size of an object is larger than eight eightbytes, or it contains un- aligned fields, it has class MEMORY. 2. If a C++ object is non-trivial for the purpose of calls, as specified in the C++ ABI, it is passed by invisible reference (the object is replaced in the parameter list by a pointer that has class INTEGER). 3. If the size of the aggregate exceeds a single eightbyte, each is classified separately. Each eightbyte gets initialized to class NO_CLASS. 4. Each field of an object is classified recursively so that always two fields are considered. The resulting class is calculated according to the classes of the fields in the eightbyte: (a) If both classes are equal, this is the resulting class. (b) If one of the classes is NO_CLASS, the resulting class is the other class. (c) If one of the classes is MEMORY, the result is the MEMORY class. (d) If one of the classes is INTEGER, the result is the INTEGER. (e) If one of the classes is X87, X87UP, COMPLEX_X87 class, MEM- ORY is used as class. (f) Otherwise class SSE is used. > При добавлении нестандартного [[clang::trivial_abi]] "Google has measured performance > improvements of up to 1.6% on some large server macrobenchmarks, and > a small reduction in binary sizes" - https://libcxx.llvm.org/DesignDocs/UniquePtrTrivialAbi.html И что?
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 07-Мрт-25, 04:38
	> И что? И ничего. > Не вижу запрета И что? Если хочется что-то сказать или уточнить по поводу накладных расходов у std::unique_ptr, то сказал бы. Если не хочется, то стоило ли начинать?
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 07-Мрт-25, 11:59
	>> Не вижу запрета > И что? Поскольку заявление "ABI запрещает передавать его через регистры" не подтверждено требованием из System V Application Binary Interface AMD64 Architecture Processor Supplement, считаю его ложным. > Если хочется что-то сказать или уточнить по поводу накладных расходов у std::unique_ptr, > то сказал бы. Я уточнил, когда делал свою реализацию std::unique_ptr до принятия стандарта, Clang тогда не существовал. Сейчас мне любопытно одно: где прописан запрет? > Если не хочется, то стоило ли начинать? Советую не начинать. >> И что? > И ничего. Действительно.
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 07-Мрт-25, 13:45
	Я не папа римский и даже свой unique_ptr не писал. Могу сослаться на P2028[1] и спросить, в чём тогда он ошибается? И почему не стали передавать через регистры? [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20... : The largest example we have for issues with the calling convention comes from passing unique_ptr. For the Itanium ABI (used on Linux systems, among others), any type with a destructor that is passed by value must be passed in memory: the address held in this unique_ptr must be written out to memory (and then potentially re-fetched in the calling function), rather than passed in registers as it would be for a raw T*. Had implementers and the specifiers of the Itanium ABI agreed to specialize the handling of unique_ptr<T> passed by value, it could perhaps be no more expensive than a raw T*. That wasn’t done before unique_ptr<T> was introduced, and thus now it would be an ABI break to change the calling convention without updating all callers and callees in sync.
	Ответить | Правка | Наверх | Cообщить модератору

	326. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 08-Мрт-25, 16:30
	В стандарте Си++ (ссылкой на ISO/IEC 9899) "запрещено" записывается как "shall not". 4. Conformance 1 In this International Standard, ‘‘shall’’ is to be interpreted as a requirement on an implementation or on a program; conversely, ‘‘shall not’’ is to be interpreted as a prohibition. "Не стали" и "запрещено" несколько разные вещи. Есть требование передавать ссылку, "If a C++ object is non-trivial for the purpose of calls". Например, когда вызывается экспортируемая модулем (.so) функция, надо иметь возможность вызвать деструктор. Если же вызываемая функция связывается с другими в один модуль, то оптимизатору не запрещено поступать как ему заблагорассудится, вплоть до встраивания.
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 09-Мрт-25, 00:37
	> В стандарте Си++ (ссылкой на ISO/IEC 9899) "запрещено" записывается как "shall not". Запрещает ABI, не стандарт C++. В стандарте C++ нет такого понятия, как ABI. > "Не стали" и "запрещено" несколько разные вещи. Не стали - в реализациях стандартной библиотеки. Запрещено - в ABI (в Itanium ABI и в "менее формальных ABI", возникающих из нежелания ломать совместимость между версиями). Лежит непотревоженным - стандарт C++. > Если же вызываемая функция связывается с другими в один модуль, то оптимизатору не запрещено поступать как ему заблагорассудится, вплоть до встраивания. Но это ведь связано не с определением "non-trivial for..."[1], а с исчезновением необходимости придерживаться определённого ABI. [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#non-trivial : non-trivial for the purposes of calls     A type is considered non-trivial for the purposes of calls if:         it has a non-trivial copy constructor, move constructor, or destructor, or         all of its copy and move constructors are deleted.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Cooler (??), 07-Мрт-25, 09:36
	Пример притянут за уши. При передаче std::unique_ptr<…>, как аргумент функции "по значению", вы ещё и передаёте владение объектом. Что отличается от передачи raw-pointer. Как говорится - "чем пользуетесь, за то и платите".
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	291. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 07-Мрт-25, 13:28
	Уши растут из заявления "std::unique_ptr<…> - zero-cost". > Как говорится - "чем пользуетесь, за то и платите". Это первая часть смысла zero-overhead abstraction по-страуструповски. А вот вторая, которая нарушается: "What you do use, you couldn’t hand-code any better".
	Ответить | Правка | Наверх | Cообщить модератору

	293. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Cooler (??), 07-Мрт-25, 13:47
	Вот из-за таких демагогов и гибнут проекты. Главное победить на словах перед начальством. А то что из-за профессиональной близорукости накрылся проект - они даже осознать это не в состоянии. Потому что, всегда были правы в болтовне. Ни одного факта не привёл, всё свелось к пересказу чужих мыслей, пусть даже и не до конца их понимая.
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 07-Мрт-25, 13:56
	"Простите, часовню тоже я развалил?"* Мы одну фразу обсуждаем: "std::unique_ptr<…> - zero-cost". И нафига брать выражение Струструпа, вкладывать в него свой другой смысл и из-за этого заламывать руки?
	Ответить | Правка | Наверх | Cообщить модератору

	296. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 07-Мрт-25, 14:06
	* Страуструпа И где демагогия-то? n00by не согласен с тем, что ограничение берётся из ABI. А ты хочешь сказать, что ограничения с соответствующим оверхедом вовсе не существует? Или хочешь постараться ничего однозначного не говорить?
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Cooler (??), 07-Мрт-25, 14:37
	Я хочу сказать, что некорректно сравнивать два семантически разных вызова функций. void foo(bar* ptr); // не определено, кто владеет ptr И void foo(std::unique_ptr<bar> ptr); // передача владения внутрь функции Решают две разные задачи.
	Ответить | Правка | Наверх | Cообщить модератору

	299. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 07-Мрт-25, 16:01
	Если вернуться к > 50. Карлос Сношайтилис: >    — У нас есть классы и оно zero-cost! (vtable не считается) >    — У нас есть умные указатели и они zero-cost! (игнорируем счётчик ссылок) То я с ним тоже не согласен и ещё написал в другой ветке про девиртуализацию. Но если перейти к "std::unique_ptr<…> - zero-cost", то это не zero-cost, потому что мы платим за неоптимальность по сравнению с другой возможной реализацией владеющего указателя. Эта другая реализация ломает обратную совместимость (тоже ABI, в общем-то) и вроде бы немного нарушает стандарт и спрятана за _LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI в одном компиляторе.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Cooler (??), 07-Мрт-25, 18:01
	Не согласен. std::unique_ptr<X> - по размеру такой же как и X*. std::unique_ptr<X> - по скорости доступа к объекту X, такой же, как и X*. Когда вы применяете move() семантику, то используете свойство которым не обладает raw-pointer. И здесь, возможно, придётся немножко доплатить.
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

	310. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 07-Мрт-25, 20:30
	> Когда вы применяете move() семантику, то используете свойство которым не обладает raw-pointer. В C# можно найти много новых свойств по сравнению с ассемблером или Cи (и при необходимости опуститься хоть до CIL). Если их на этом основании объявить zero-cost, то нас не поймут, а то и поколотят и правильно сделают. Страуструп этот тонкий момент чувствовал и говорил не только про "не используешь - не платишь", но и про "используешь - имеешь оптимальную реализацию". Поэтому с "придётся немножко доплатить" надо считаться. "No run-time overhead compared to good hand-crafted code (the zero-overhead principle)"[1] Большой оверхед на владеющие указатели недопустим, поэтому дальше идёт рассказ про, внезапно, gsl::owner[2]. "Lack of resources" упоминается среди причин для его использования[3]. Новые возможности классов по сравнению с сишными структурами - это ещё не повод иметь объекты только на куче и передавать только по ссылке (а ведь это подходит под "не используешь - не платишь", если сишные структуры тоже оставить)[4]. [1] https://www.stroustrup.com/resource-model.pdf#page=4 [2] https://www.stroustrup.com/resource-model.pdf#page=7 [3] https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines... [4] https://www.stroustrup.com/ETAPS-corrected-draft.pdf#page=4
	Ответить | Правка | К родителю #300 | Наверх | Cообщить модератору

	311. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 07-Мрт-25, 20:49
	> если сишные структуры тоже оставить * Тоже оставить существовать параллельно с новинками. ** Текст под [2] и [4] - вольный пересказ тех страниц.
	Ответить | Правка | К родителю #310 | Наверх | Cообщить модератору

	312. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Cooler (??), 07-Мрт-25, 21:10
	Не имея мозгов, и на ассемблере можно написать программу медленнее Питона. Никто не предлагает делать std::move() для std::unique_ptr<> несколько миллионов раз в секунду. А тем кто так делает, надо сменить профессию. Основные операции с указателями - разыменование и сравнение с чем-либо. Здесь оверхэда не будет. Каждая языковая конструкция имеет свою область применения. Использовать везде shared_ptr<X> вместо X*, а потом кричать про оверхэд - непрофессионально. Использовать виртуальные функции везде, вместо обычных - тоже показатель отсутствия архитектуры в программе. "используешь - имеешь оптимальную реализацию" - здесь сразу встаёт вопрос о критериях оптимальности. По каким параметрам оцениваем оптимальность? Не всегда производительность является решающим параметром. "... это ещё не повод иметь объекты только на куче и передавать только по ссылке" - про это вообще не понял к чему? И вообще - очень много общих слов, хотя и красивых. Хотелось бы конкретики, с примерами кода.
	Ответить | Правка | К родителю #310 | Наверх | Cообщить модератору

	314. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 08-Мрт-25, 02:29
	> "используешь - имеешь оптимальную реализацию" - здесь сразу встаёт вопрос о критериях > оптимальности. По каким параметрам оцениваем оптимальность? Не всегда производительность > является решающим параметром. Ну а какой оверхед может быть в рантайме? Память, производительность. И так как std::unique_ptr - инструмент общего назначения, то ориентироваться на общие, усреднённые потребности. > "... это ещё не повод иметь объекты только на куче и передавать > только по ссылке" - про это вообще не понял к чему? Страуструповский взгляд на допустимые накладные расходы. Со страницы по ссылке. "In general, C++ implementations obey the zero-overhead principle ... Compare this with a more typical layout from a “pure object-oriented language” where each user-defined object is allocated separately on the heap and accessed through a reference". > И вообще - очень много общих слов, хотя и красивых. В его возрасте ожидаемо. Да и обсуждаемый принцип (zero-cost, он же zero-overhead) - он такой, общий и красивый. > Хотелось бы конкретики, с примерами кода. Эта просьба подразумевает, что разработчики кланга с их _LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI - не очень умные люди, как и пользователи этой опции. Либо зачем-то предлагает поторговаться насчёт точной величины того ~1% производительности И то, и другое сомнительно.
	Ответить | Правка | К родителю #312 | Наверх | Cообщить модератору

	327. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 08-Мрт-25, 16:39
	>> Хотелось бы конкретики, с примерами кода. > Эта просьба подразумевает, что разработчики кланга с их _LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI > - не очень умные люди, как и пользователи этой опции. > Либо зачем-то предлагает поторговаться насчёт точной величины того ~1% производительности Они очень умные, а потому не воюют открыто с GCC и его оборюзгшей библиотекой. 1% это такая мелочь в 2к25, но они целенаправленно добиваются своего.
	Ответить | Правка | К родителю #314 | Наверх | Cообщить модератору

	168. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (166), 05-Мрт-25, 11:41
	Вообще-то ничто не мешает в C ручками прикрутить vtable, чтобы полиморфизм симитировать.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	232. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (230), 05-Мрт-25, 23:09
	И если при этом не будет автоматической девиртуализации по возможности, то тогда плюсы становятся negative-cost!
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 06-Мрт-25, 14:10
	> И если при этом не будет автоматической девиртуализации по возможности, то тогда плюсы становятся negative-cost! Не будет. Эмуляция ООП на Си работает медленнее. Ибо все проверки в рантайм и нет оптимизаций.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (26), 04-Мрт-25, 22:46
	Заголовочный файл + плагин для компилятора. > ... но после проверки исходного кода плагин можно вообще не использовать, поскольку он только анализирует AST, но не вносит в него никаких исправлений.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

6. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
Сообщение от Аноним (6), 04-Мрт-25, 22:12
Костыль не принимается, только новая нога.
Ответить | Правка | Наверх | Cообщить модератору

	11. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Bottle (?), 04-Мрт-25, 22:18
	Аналогия изначально хорошая, поскольку при попытке приживить новую ногу всю жизнь придётся пользоваться имунноподавляющими лекарствами. Костыль или протез подобного не требуют.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Гентушник (ok), 05-Мрт-25, 15:37
	Можно взять ногу от близнеца. Близнеца можно сделать клонированием, желательно заранее, уже при рождении человека (типо страховка такая).
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (12), 04-Мрт-25, 22:19
	Но их у ц++ уже и так 20, куда уж больше?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

16. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
Сообщение от Аноним (16), 04-Мрт-25, 22:27
Походу особо одаренным, просто религия не позволяет использовать и/или С++ и/или Rust. Хз, в чём проблема то? - жесть!
Ответить | Правка | Наверх | Cообщить модератору

	36. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (35), 04-Мрт-25, 22:59
	Проблема-то проста. Изучи и то и другое на норм уровень и не вырви мозгом
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+6 +/–
	Сообщение от Аноним (49), 05-Мрт-25, 00:09
	Достаточно знать программирование на «норм» уровне, и язык программирования перестанет иметь такое большое значение и становится всего лишь средством достижения цели. Да, какие-то языки лучше подходят для решения каких-то задач в каких-то доменах, какие-то меньше. К каким-то душа лежит, а к каким-то не лежит. На каких-то писать можно только за зарплату, а на каких-то ещё и для души. Но это сиюминутные мелочи. Скилл — он совсем в другой плоскости лежит.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+6 +/–
	Сообщение от Аноним (65), 05-Мрт-25, 01:00
	Это бесполезно объяснять удушенным Яндекс практикумом "мега питон синьор помидор".
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
	Сообщение от n00by (ok), 05-Мрт-25, 07:56
	А зачем им это объяснять? Пусть себе воюют. Где бы их для этого обособить, что бы остальным мозг не клевали - вот вопрос.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Арман (?), 05-Мрт-25, 08:53
	Жму вам всем руки, товарищи адекваты. Здоровья.
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (49), 05-Мрт-25, 17:23
	Их и обособили, здесь на опеннете.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	217. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (217), 05-Мрт-25, 19:11
	Считать что хороший программист на С/С++ освоит новый язык в совершенстве за две недели/месяц/год - это профнепригодность!
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	237. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (49), 06-Мрт-25, 06:29
	А в совершенстве что-то знать не только невозможно, но и не нужно. Нужно конкретные прикладные задачи решать на приемлимом уровне. Для хорошего программиста изучение языка на уровне, соответствующем уровню проекта не является сложной задачей. Ещё раз повторю: скилл лежит совершенно в иной плоскости. Не в плоскости языков программирования, тулчейнов, редакторов, ДЕ, ОС, или клавиатурных раскладок.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (217), 06-Мрт-25, 08:11
	Приемлемый уровень - это "середнячок". Этого точно достаточно чтобы писать качественный и безопасный код? Да... это явно выходит за рамки профнепригодности.
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (49), 06-Мрт-25, 18:21
	> Приемлемый уровень - это "середнячок". Этого точно достаточно чтобы писать качественный и безопасный код? Точно, доказано и показано на практике всей софтверной индустрией, год от года. Практически весь код на этой планете написан посредственными программистами. Даже если ты гений один на миллион, в одном только NYC вас таких восемь, а нужно — от силы два, и оба уже трудоустроены. Задач столько нет, чтобы всех гениев занять.
	Ответить | Правка | Наверх | Cообщить модератору

	273. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (217), 06-Мрт-25, 18:37
	Был бы гений, а задача найдется. Да и речь шла не о них...
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 10:33
	> Считать что хороший программист на С/С++ освоит новый язык в совершенстве за > две недели/месяц/год - это профнепригодность! "на С/С++" уже само по себе маркер. ;)
	Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

	252. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (-), 06-Мрт-25, 11:47
	> "на С/С++" уже само по себе маркер. ;) А какая разница? (с) Что первое дырявое поделие с кучей типичных проблем, что второе, судя по нытью Страуструпа) Учитывая все ВНЕЗАПНО появившиеся попытки "а давайте сделаем ЯП хоть немного безопаснее" то это начали осознавать и другие люди.
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 06-Мрт-25, 13:02
	Путаешь теплое с мягким. Не ЯП хотат сделать безопасным, а хотят добавить инструменты, которые будут отрезать указанную функциональность для указанных артефактов программы. А ЯП как был так и останется.
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (217), 06-Мрт-25, 13:57
	Не совсем понятно, о чём идёт речь?
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	285. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 07-Мрт-25, 12:09
	Кто более-менее знает языки, тот не пишет "на С/С++".
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (217), 07-Мрт-25, 14:29
	Львиная доля всего программного обеспечения написано на С/С++, а вы озвучивает подобную ерунду. Как себя чувствуете?
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (49), 07-Мрт-25, 18:12
	Когда приходится собеседовать кандидатов, всегда ищу и рекомендую к найму тех, которые любят не языки и дистрибутивы, а тех которые умеют программировать и админить системы. Языкам и особенностям дистрибутивов научить можно довольно легко. Научить думать — крайне тяжело. Научить видеть лес за деревьями — практически невозможно.
	Ответить | Правка | Наверх | Cообщить модератору

	309. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (-), 07-Мрт-25, 20:14
	> Когда приходится собеседовать кандидатов, всегда ищу и рекомендую к найму тех, которые любят не языки и дистрибутивы, Почему же? Если владение тем или иным дистрибутивом это отличный показатель. Например если соискатель начинает рассказывать про слаку или диван - то понятно что это пердолик-нетакусик, который будет лепить костыли и для командной работы слабо пригоден. > а тех которые умеют программировать и А как ты это проверишь)? > админить системы. Админиить можно научить даже камаку. Тут особо мозги не нужны. > Языкам ... научить можно довольно легко. На каком уровне? Если на уровне "не сошлись типы - кастуй к void*" то да. Но это не программирование, а халтура)
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 08-Мрт-25, 15:38
	Собственно, программирование -- это когда берётся "маленький кусочек бытия", абстрагируются от деталей и записывают на понятном машине языке. В таком раскладе язык подбирается (в частном случае, создаётся) под задачу. Но иногда нужны и программисты на определённом языке, или нескольких. Как бы то ни было, знатоки "языка С/С++" к последним не относятся, так что в любом раскладе не очень годны.
	Ответить | Правка | К родителю #301 | Наверх | Cообщить модератору

	324. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 08-Мрт-25, 15:28
	>> Кто более-менее знает языки, тот не пишет "на С/С++". > Львиная доля всего программного обеспечения написано на С/С++, а вы озвучивает подобную > ерунду. Знаю ПО написанное на Си. Знаю ПО написанное на Си++. Знаю ПО написанное на Си и Си++. Хотелось бы увидеть ссылочку на "написано на С/С++". > Как себя чувствуете? Прекрасно чувствую. Но подозреваю, что вместо ссылки начнётся, как тут любят писать, "бред": во-первых, моё утверждение подменено левым (угу, кавычки несут смысл), во-вторых, "у кого что болит".
	Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

	329. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (217), 09-Мрт-25, 02:10
	Где-нибудь, хоть словом обмолвился о том, что С/C++ - это один язык? Придумали подобную глупость, так еще и меня в этом обвинили...
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от bOOster (ok), 05-Мрт-25, 08:41
	> Походу особо одаренным, просто религия не позволяет использовать и/или С++ и/или Rust. > Хз, в чём проблема то? - жесть! Концептуально Rust сырой. Предположим написали уже гору софта, а расто-маны раз и очередной раз поменяли концептуальные основы языка, так как концепция просто не предусматривала какой-нибудь ВАЖНОЙ мелочи. Тем более такое уже было. Понятны последствия? Рассказать чем закончилось это в прошлый раз? Именно после такого "финта ушами" - я пересмотрел вообще отношение к расту.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	138. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от morphe (?), 05-Мрт-25, 09:58
	> Тем более такое уже было. Понятны последствия? После Rust 1.0? Когда и что это такое было?
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–3 +/–
	Сообщение от bOOster (ok), 05-Мрт-25, 10:01
	>> Тем более такое уже было. Понятны последствия? > После Rust 1.0? Когда и что это такое было? Так было или не было? И какие гарантии у Ржи что такого не будет в дальнейшем? У С, С++ стандартизация есть и эта стандартизация работа комитета с серьезными участниками. В случае Ржи - толпа маргиналов.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от incorporate (?), 05-Мрт-25, 10:25
	MEMSAFE - очередной нестандартизированный костыль для плюсов. Крупным производителям ПО нужен язык, генерирующий быстрый код с минимальными затратами на отладку крупных проектов. И чтобы индусы были подешевле. Ну а вы продолжайте лениво ковырять сишечкой свой никому не нужный DIY, никому нет до этого дела
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от morphe (?), 05-Мрт-25, 11:06
	>>> Тем более такое уже было. Понятны последствия? >> После Rust 1.0? Когда и что это такое было? > Так было или не было? Ты скажи, ты же это заявление сделал. А официально у Rust сказано что ломающие изменения могут быть только в editions, новая версия компилятора будет компилировать код написанный под старый edition, и в одном проекте ты можешь смешивать пакеты написанные под разные editions. https://github.com/rust-lang/rfcs/blob/master/text/2052-epoc... В целом это не особо отличается от плюсовых стандартов, за тем исключением что Rust компилятор умеет все editions и строго их разделяет, а msvc/gcc/clang каждый имеет своё подмножество поддерживаемых, и иногда это не спасает от того что код перестаёт компилироваться при обновлении компилятора. > И какие гарантии у Ржи что такого не будет в дальнейшем? У Rust строгий, прозрачный, и демократичный RFC процесс, вся история развития языка в публичном доступе, по любому изменению ты можешь прочитать дискуссию, какие были альтернативы, и т.д. > С, С++ стандартизация есть и эта стандартизация работа комитета с серьезными > участниками. Вот только по итогу эти серьёзные участники друг с другом спорят по поводу изменений стандартов и в итоге приходят к неприятным для всех компромиссам без возможности сообществу внести свои предложения, а GCC/LLVM эти стандарты читают как хотят, и половину предложенных стандартов не реализуют.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	170. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от bOOster (ok), 05-Мрт-25, 11:44
	>[оверквотинг удален] >> И какие гарантии у Ржи что такого не будет в дальнейшем? > У Rust строгий, прозрачный, и демократичный RFC процесс, вся история развития языка > в публичном доступе, по любому изменению ты можешь прочитать дискуссию, какие > были альтернативы, и т.д. >> С, С++ стандартизация есть и эта стандартизация работа комитета с серьезными >> участниками. > Вот только по итогу эти серьёзные участники друг с другом спорят по > поводу изменений стандартов и в итоге приходят к неприятным для всех > компромиссам без возможности сообществу внести свои предложения, а GCC/LLVM эти стандарты > читают как хотят, и половину предложенных стандартов не реализуют. Этот бред даже комментировать желания нет.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (-), 05-Мрт-25, 11:50
	>> а GCC/LLVM эти стандарты читают как хотят, и половину предложенных стандартов не реализуют. > Этот бред даже комментировать желания нет. А зря. Потому что это не бред. Просто открываешь en.cppreference.com/w/cpp/compiler_support и видишь что НИ ОДИН компилятор не реализует C++23 core language или C++23 library features  полностью. Ни один, Карл! Вот такой классный стандарт, который к исполнению не обязателен. "Стандарт — это просто свод указаний, а не жёстких законов.​​" (с)
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–2 +/–
	Сообщение от деанон (ok), 05-Мрт-25, 12:50
	Занеси денег разработчикам, тогда будут тебе фичи, которые скажешь
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 05-Мрт-25, 13:17
	В самом стандарте есть механизмы предусматривающие возможность реализации не всего стандарта. И так ДОЛЖНО быть. Когда контора начинает разработку - то производится анализ целевых платформ и формируется список функциональностей из стандартов которые можно использовать. Других вариантов для множества компиляторов быть не может.
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	189. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от анонимусс (-), 05-Мрт-25, 13:56
	> В самом стандарте есть механизмы предусматривающие возможность реализации не всего стандарта. Значит это плохой стандарт. > И так ДОЛЖНО быть. Нет. Например для того чтобы иметь право называться "компилятор языка АДА" нужно не только реализовать все что написано в спеке, но еще пройти примерно 1000 тестов (по принципу "хотя бы один завалил - на выход") и сертификацию. Вот такой подход для надежных систем, а не "тут мы делаем, а тут рыбу заворачиваем". > Когда контора начинает разработку - то производится анализ целевых платформ и формируется список функциональностей из стандартов которые можно использовать. А его кто-то проводил? > Других вариантов для множества компиляторов быть не может. Могут быть компиляторы которые написаны на разных языках или просто разными командами. Но если они полностью реализуют стандарт и выдают одинаковый результат - то это хорошие компиляторы.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–2 +/–
	Сообщение от Аноним (180), 05-Мрт-25, 14:40
	> Значит это плохой стандарт. С вашей точки зрения "плохой". А так - единственно возможный. > Например для того чтобы иметь право называться "компилятор языка АДА" И где теперь эта АДА? > А его кто-то проводил? Именно. Выдается список чего можно использовать, а чего нет. Возможно не полный, но как только сборка одним из компиляторов нужной версии с нужными флагами обламывается - список пополняется. > Но если они полностью реализуют стандарт и выдают одинаковый результат - то это хорошие компиляторы. Значит вы ничего в компиляторах не понимаете. Они принципиально не могут выдать одинаковый результат. Их результат может работать одинаково - плюс/минус. Но это уже совсем другая история.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от анонимусс (-), 05-Мрт-25, 14:48
	> С вашей точки зрения "плохой". А так - единственно возможный. Что значит "единственно возможный"? Я примел пример других вариантов. > И где теперь эта АДА? Работает там куда дырявые плюсы не пустят) > Значит вы ничего в компиляторах не понимаете. Они принципиально не могут выдать одинаковый результат. Что значит не могут? Я же не про побайтовую совместимость, а чтобы не было ситуации "скомпилировал шлангов - все работает, перешел на ГЦЦ - программу начала убивать юзеров". > Их результат может работать одинаково - плюс/минус. Но это уже совсем другая история. Вот для результата "работать плюс-минус" это уже просто максимальная херня. Про "переносимость" можно забыть. Про корректность - тоже. Прибиваем написанный код к определенной версии определенного компилятора и радуемся.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (180), 05-Мрт-25, 15:08
	> Работает там куда дырявые плюсы не пустят) На которой пишут полтора землекопа? > Что значит не могут? Я же не про побайтовую совместимость, а чтобы не было ситуации "скомпилировал шлангов - все работает, перешел на ГЦЦ - программу начала убивать юзеров". А временные характеристики на это повлиять не как не могут? А если могут, то > Я же не про побайтовую совместимость Как разный бинарный код обеспечит одинаковые временные характеристик? > Прибиваем написанный код к определенной версии определенного компилятора и радуемся. Именно так и делают разработчики rust и другого В разработке нормальной же чем больше компиляторов и платформ используется в тестах - тем лучше будет код. Даже если реально он используется одним компилятором на одной платформе.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (-), 05-Мрт-25, 17:16
	> На которой пишут полтора землекопа? Ой, а когда это количество погромистов стало признаком качества? Если так судить, то пик развития программеров и яп это пыха и js. Зато наверное вся авиация летает на АДА. Самолеты конечно падают... но какой бы ужас творился если бы туда пустили плюсы или дыряшку!
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 06-Мрт-25, 12:17
	> Ой, а когда это количество погромистов стало признаком качества? > Если так судить, то пик развития программеров и яп это пыха и js. > Зато наверное вся авиация летает на АДА. Самолеты конечно падают... Мало того что падали, так и падали именно из-за проблем с программным обеспечением. И тут две причины. 1-я невыразительность языка, где тебя обязывают использовать то, что тебе не нужно. 2-я малой число программистов, а, следовательно, малая конкуренция среди них. И в итоге критически важным программным обеспечением занимаются люди к этому не пригодные. > но какой бы ужас творился если бы туда пустили плюсы или дыряшку! В машинах работают. И требования в них намного жестче. С чего бы не работать в самолетах?
	Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

	177. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от деанон (ok), 05-Мрт-25, 12:48
	Веганская этичная горизонтальная сейфспейс разработка. Мы поняли
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

21. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–6 +/–
Сообщение от Аноним (-), 04-Мрт-25, 22:30
Ахаха! Как забегали, как засуетились! Теперь ждем гору различных и при том несовместимых решений для плюсов. В идеале - чтобы они еще конфликтовали друг с другом)) Вот это будет представление! Уже запасаюсь попкорном))
Ответить | Правка | Наверх | Cообщить модератору

	141. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от bOOster (ok), 05-Мрт-25, 10:03
	> Ахаха! > Как забегали, как засуетились! > Теперь ждем гору различных и при том несовместимых решений для плюсов. В > идеале - чтобы они еще конфликтовали друг с другом)) > Вот это будет представление! Уже запасаюсь попкорном)) Разнообразие решений приведет к выбору лучшего. Разнообразие это всегда отлично. В отличии от кучки ржавых маргиналов с манией величия - нагнем всех, что продиктуем - то и будете пользвоать.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от incorporate (?), 05-Мрт-25, 10:29
	Противоречите сам себе. "Разнообразие это всегда отлично"?
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 10:39
	> Противоречите сам себе. "Разнообразие это всегда отлично"? В прямом смысле. Каждый "разнообразный" отличен от остальных.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (-), 05-Мрт-25, 11:45
	> Разнообразие решений приведет к выбору лучшего. Разнообразие это всегда отлично. Это от создателей "зачем в ядре 2 языка" и "да что эти, с крашенными волосами, себе позволяют!11" ? Или ЭТО_ДРУГОЕ™ ? > В отличии от кучки ржавых маргиналов с манией величия - нагнем всех, Хахахаха, сначала сделайте что-то нормально работающее, нагибаторы мамкины > что продиктуем - то и будете пользвоать. Пока шанс того, что дырявые языки выкинут из госконтрактов существенно больше.
	Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

	179. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от деанон (ok), 05-Мрт-25, 12:57
	Ты явно не понимаешь как устроена разработка
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Соль земли (?), 05-Мрт-25, 10:55
	Напиши это со своего браузера, тогда поговорим.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

32. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
Сообщение от _erthink (?), 04-Мрт-25, 22:48
Ой молодцы, пойду задоначу
Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от Аноним (46), 04-Мрт-25, 23:59
Чтобы растовики отстали, но пользоваться все равно никто этим не будет.
Ответить | Правка | Наверх | Cообщить модератору

	53. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 00:11
	А растовикам зачем приставать к плюсовикам? Их и у себя хорошо кормят
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (78), 05-Мрт-25, 02:35
	да постоянно плюсы помоями поливают, а потом берут LLVM написанный на С++ и идут свои хелоувроты компилировать.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 08:00
	Помоями поливают Раст. "Кривой синтаксис", "ничего не написано", "безопасность с ансейф" и пр. Знакомо? А растоманы пользуются трудами других людей и в ус не дуют. > потом берут LLVM написанный на С++ Если ты видишь в этом проблему или идеологическое несоответствие, то как же ты используешь ядро, написанное на С? Или это другое?
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (78), 05-Мрт-25, 10:31
	> Или это другое? Конечно другое, мне нравится Си и считаю что весь системный софт, ОС и ядра с дровами должны быть написаны на нем.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (166), 05-Мрт-25, 11:43
	Безопасность с ансейф называется безопасТность.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	155. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от incorporate (?), 05-Мрт-25, 10:35
	Процессору пофиг на чем ты свой хелловрот писал. Процессор умеет лишь в свой набор команд, слабо скормить процессору нативный си++ код? А что так?
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	157. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (78), 05-Мрт-25, 10:38
	Процессору то пофиг. Вот только машинные коды получаются не идентичные взасимости от того на каком ЯП был написан код, какие ключи оптимизации были использованы, какая версия компилятора и тд.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (88), 05-Мрт-25, 05:12
	> А растовикам зачем приставать к плюсовикам? Хз. Петушатся, дыряшки им везде мерещатся...
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

52. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 00:10
Это новый MiraclePtr? А что со старым, не взлетел?
Ответить | Правка | Наверх | Cообщить модератору

62. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
Сообщение от Аноним (-), 05-Мрт-25, 00:46
Командная строка для запуска компилятора с плагином:      clang++ -std=c++20 -Xclang Но где же гнутелла?)) А вообще лучше трижды подумать чем завязываться на какое-то нестандартизированное поделие мутного васяна... Плюсы не просто так стандартизировали, поэтому вот когда в стандарт добавят и реализуют в компиляторах - тогда и использовать можно будет.
Ответить | Правка | Наверх | Cообщить модератору

	84. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (84), 05-Мрт-25, 04:48
	Возможно, единственный адекватный комментатор под этой новостью.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+3 +/–
	Сообщение от Аноним (94), 05-Мрт-25, 06:36
	Цены ему не было бы если бы он ещё дочитал до конца новости что это "нестандартизированное поделие" не влияет на генерируемый код.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (132), 05-Мрт-25, 09:32
	То есть вы себя не включили в разряд адекватных? Бывает.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	279. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (84), 07-Мрт-25, 03:51
	Да.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 05-Мрт-25, 13:22
	Ты собираешь компилятором gcc код. Собираешь его clang'ом с плагином. И там и там соберётся. Как clang c плагином повлияет на собранный gcc код?
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	188. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (-), 05-Мрт-25, 13:51
	> Ты собираешь компилятором gcc код. > Собираешь его clang'ом с плагином. О... т.е. вы предлагаете мне не просто тащить еще 100500Гб мусорного шланга в систему, но еще и заставляете использовать несвободный софт? Ради чего? Чтобы пару CVE не сделать? Не дождетесь! Одной CVE больше, одной меньше. Переживете.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (26), 05-Мрт-25, 14:40
	Какой из компиляторов является не свободным, gcc или Clang?
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–3 +/–
	Сообщение от Аноним (215), 05-Мрт-25, 18:13
	clang не свободный. По лицензии gcc нельзя посадить под замок
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (-), 05-Мрт-25, 18:21
	> Какой из компиляторов является не свободным, gcc или Clang? Clang - свободный. А GCC - нет. Они даже в свое время пытались провернуть "все что скомпиленно gcc заражается GPL". Приколько конечно - твой код кто-то скомпилировал, теперь его надо открывать под гну-раком. Их конечно знатно накормили и пришлось костылить GCC Runtime Library Exception. Но работать с такими копирастами.. просто себя не уважать)
	Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

	263. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (180), 06-Мрт-25, 13:06
	Битва сектантов. И то и другое инструмент. Разрабатывать можно на всех доступных. Не нравится лицензия в прод пускай сборку тем, что нравится.
	Ответить | Правка | Наверх | Cообщить модератору

68. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
Сообщение от Neon (??), 05-Мрт-25, 01:01
Опять костыли. Куда то С++ пошел явно не туда после 11 и 14 версий. И чем дальше, тем сильнее не туда. Вместо учета пожеланий прикладных программистов все новшества исключительно для разработчиков самого С++ и его стандартной библиотеки, всё для себя любимых. Да и сама стандартная библиотека С++ какой то бред воспаленного ума, бред в горячке у Степанова. Неудобная, с идиотской архитектурой, с синтаксисом явно нечеловеческим. Вместо поддержки сети, например, зачем то эллиптические функции добавлены в стандартную библиотеку, хотя большинству программистов именно сеть нужна, а не эти функции. Даже поддержка строк сделана явно через ж@пу.
Ответить | Правка | Наверх | Cообщить модератору

	70. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Карлос Сношайтилис (ok), 05-Мрт-25, 01:12
	Не время думать о строках, указатели в опасности!
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (88), 05-Мрт-25, 01:21
	Могли бы, например, просто функции для прикладных задач из PHP в стандартную библиотеку Си++ перенести. Так нет же, маялись сплошным переусложнением ради переусложнения. На хабре эта тема уже поднималась, пришли к аналогичному выводу. Ладно, что есть то есть. К сожалению, пришлось на плюсах самому переизобретать некоторые вещи по итогу, свои классы обёртки писать, чтобы упростить Си++ до удобочитаемости скриптового языка для быстрого прототипирования.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	72. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (88), 05-Мрт-25, 01:24
	Да, и строку тоже пришлось свою делать, т.к. пользоваться этим стандартным убожеством нет никакого желания. Получилось гораздо многофункциональнее, удобнее, проще. Я понимаю, велосипедостроение, но это реально - был шаг от отчаяния.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	110. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (110), 05-Мрт-25, 08:42
	>Да, и строку тоже пришлось свою делать, т.к. пользоваться этим стандартным убожеством нет никакого желания. Получилось гораздо многофункциональнее, удобнее, проще. Голосом Каневского: "Многофункциональнее, удобнее и проще конечно ни у кого не получилось" (c) Каждый велосипедист строк в плюсах обречен писать глючное подмножество стандартного решения, которое подмножество "не тормозит" из-за срезанных примерно всех углов квадратных колес велосипеда, и ломается примерно сразу в любых более других входных условиях, о которых велосипедист не подумал. А "проще" оно потому что максимально наивное. >но это реально - был шаг от отчаяния. "Не умеешь решить задачу в общем виде, пили велосипед для своего частного случая".
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (88), 05-Мрт-25, 13:57
	Наивно полагать, что "комитетчики" решили задачу в общем виде. Они её решили просто безобразно.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 10:44
	Утверждать "решили в общем виде" можно на основании того, что basic_string вписываются к концепцию алгоритмов-итераторов STL. И голословно охаивать "можно" -- закон не запрещает.
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от 823008 (?), 06-Мрт-25, 11:46
	Непереводимая игра слов?
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 12:30
	Эксплуатация уязвимости парсеров с закольцованным входным буфером малого объёма.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от 823008 (?), 06-Мрт-25, 12:44
	Продолжайте наблюдение, мы с вами свяжемся.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 12:56
	Меня подобным не удивить - местный ботнет давно выдал все возможные тупые шаблоны.
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от 823008 (?), 06-Мрт-25, 12:58
	> Меня подобным не удивить - местный ботнет давно выдал все возможные тупые > шаблоны. Не скромничай, в этом плане ты вне конкуренции.
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от n00by (ok), 06-Мрт-25, 13:00
	Ну ещё бы. И ты тоже будешь за мной повторять. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноньимъ (ok), 05-Мрт-25, 02:50
	Оно не туда после 97 чи 99 пошло.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	112. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (110), 05-Мрт-25, 08:48
	>Оно не туда после 97 чи 99 пошло. Удачи сопровождать код из 90-х ("ехало UB через UB") в 2025-м, когда есть фичи стандартов 11++.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноньимъ (ok), 05-Мрт-25, 16:54
	>>Оно не туда после 97 чи 99 пошло. > Удачи сопровождать код из 90-х ("ехало UB через UB") в 2025-м, когда > есть фичи стандартов 11++. Там было меньше UB чем в новых стандартах.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 06-Мрт-25, 14:07
	В старых возможностях часть UB убрали. Пересмотрели целевые архитектуры и опыт реализации. Так что в базовой версии языка стало меньше. В новых, естественно, добавили. Ибо это необходимость для компилируемого переносимого языка. Так что с сумма - стало больше.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (166), 05-Мрт-25, 11:48
	>97 чи 99 А такие были? Вот 98 и 03 точно были.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	211. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноньимъ (ok), 05-Мрт-25, 16:53
	>>97 чи 99 > А такие были? Вот 98 и 03 точно были. Значит 98
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от bOOster (ok), 05-Мрт-25, 08:35
	> Опять костыли. Куда то С++ пошел явно не туда после 11 и > 14 версий. И чем дальше, тем сильнее не туда. Вместо учета > пожеланий прикладных программистов все новшества исключительно для разработчиков самого > С++ и его стандартной библиотеки, всё для себя любимых. Да и > сама стандартная библиотека С++ какой то бред воспаленного ума, бред в > горячке у Степанова. Неудобная, с идиотской архитектурой, с синтаксисом явно нечеловеческим. > Вместо поддержки сети, например, зачем то эллиптические функции добавлены в стандартную > библиотеку, хотя большинству программистов именно сеть нужна, а не эти функции. > Даже поддержка строк сделана явно через ж@пу. В ракурсе такого рассуждения - Раст это вообще сплошной костыль.. Каким образом сеть и эллиптические функции связаны? Далее - эллиптические функции связаны с защитой/шифрованием данных и могут применяться как локально так и по сети. Ну а сеть это сеть. Ее может на компе и не быть. Иногда серое вещество то включать надо.. Если оно конечно есть. Все в стандартных библиотеках сделано логично и нормально.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	114. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (110), 05-Мрт-25, 08:59
	>Да и сама стандартная библиотека С++ какой то бред воспаленного ума, бред в горячке у Степанова. Знакомые песни неосиляторов, не написавших ничего примерно никогда. Степанов показал что есть альтернативы ООП и развесистые иерархии не нужны, остальное -- "разработка комитетом" (ТМ) >Неудобная, с идиотской архитектурой, с синтаксисом явно нечеловеческим. Это производная от того, что можно было сделать с т.з. обобщенного программирования на еще тех плюсах из 90-х, где привязки к GUI библиотекам делались несопровождабельной кашей из макросов. То-то "человеческий" синтаксис. >Даже поддержка строк сделана явно через ж@пу. Недалеким и потому самоуверенным велосипедистам все время кажется что проблема строк ограничена их частным случаем. А потом по кодовой базе разбросаны их велосипеды string2, string3, string_ng...
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	134. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от bOOster (ok), 05-Мрт-25, 09:34
	> Недалеким и потому самоуверенным велосипедистам все время кажется что проблема строк ограничена > их частным случаем. А потом по кодовой базе разбросаны их велосипеды > string2, string3, string_ng... Да отрок просто не догоняет что за 256 символами ASC-II есть еще UNICOD в различных инкарнациях для абсолютно непохожих языков типа японского и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (124), 05-Мрт-25, 09:14
	Зачем тебе вообще строки, это такие же данные, как и другие.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	220. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (220), 05-Мрт-25, 19:45
	Ну да, только ассемблер, только машинный код! А реверсить его в читабельный вид и ревюить кто будет, телепаты в матрице?
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от nonstop (?), 05-Мрт-25, 11:45
	Именно так. Добавляют нужное, но с невероятно медленной скоростью. Вероятно это плата за стандартизацию, но непросто конечно с таким смириться. Добавление в STL умных указателей больше 10-ти лет заняло. Лямбды добавили, про потоки вспомнили, уже радость. Корутины завезли хоть в каком-то виде, хотя явно неродные они в языке. А ещё ведь есть строки с юникодом, сеть, дата и время, работа с базами данных... Я естественно в курсе про boost и само-собой его использую по возможности, но когда возвращаешься к родным плюсам после питона или го... Печаль в общем.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	306. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (306), 07-Мрт-25, 18:44
	>большинству программистов именно сеть нужна Не годиться в стандартную библиотеку. Возможны различные реализации.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	307. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (306), 07-Мрт-25, 18:48
	>Даже поддержка строк сделана явно через ж Измененная строка это другой объект. Прикладные программисты могут сами написать нужные библиотеки.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

106. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от bOOster (ok), 05-Мрт-25, 08:31
"на концепцию владения и заимствования из языка Rust" Причем тут Ржа? Данные методики появились задолго до раста. В расте они были реализованы в концепции языка. Я лет 20 назад баловался с похожими/идентичными идеями, но для себя использовать было лень :)
Ответить | Правка | Наверх | Cообщить модератору

	302. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (49), 07-Мрт-25, 18:14
	Методики задолго. А концепции взяли из раста как самые проработанные. ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯
	Ответить | Правка | Наверх | Cообщить модератору

108. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от Я (??), 05-Мрт-25, 08:37
Сделали бы для начала инструмент валидации указателей на уровне стандартных библиотек. Все борются с UB, созданными толпой бывших питонистов - разработчиков компиляторов в погоне за лучшей оптимизацией. Не запрещено в стандарте - значит нужно оптимизировать - выкинув лишнее, выведем предупреждение если пользователь включит флаги а, б, с, ш. именно в этом порядке.
Ответить | Правка | Наверх | Cообщить модератору

	111. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Я (??), 05-Мрт-25, 08:42
	живой пример, питонисты пролобировали добавление в стандартные библиотеки функции strdup, которая автоматически делает realloc при вызове, но что будет если указатель был в стеке или статик, в питоне все работает - вносим в стандарт.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (118), 05-Мрт-25, 09:12
	>>но что будет если указатель был в стеке или статик а что будет если Вы пойдёте на красный свет? просто этого не делайте
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Я (??), 05-Мрт-25, 10:33
	не вызывайте free два раза подряд. ржавотики говорят, что проблема языка. прохожие из городов, где все время день, рредлагают не ходить на красный.
	Ответить | Правка | Наверх | Cообщить модератору

120. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от Аноним (124), 05-Мрт-25, 09:10
Си/C++ не исправить, поэтому и появилась куча других языков, например, odin и zig. Смиритесь и живите дальше.
Ответить | Правка | Наверх | Cообщить модератору

	131. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (131), 05-Мрт-25, 09:28
	> появилась куча других языков Как появилась, так и исчезла. С C/C++ был, есть и будет.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (135), 05-Мрт-25, 09:37
	как и проблемы с памятью неужели раст исчезнет первый?
	Ответить | Правка | Наверх | Cообщить модератору

	287. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (287), 07-Мрт-25, 12:49
	Rust как был маргинальным языком программирования лет 10 назад (ныне на уровне Scratch-а судя по TIOBE) так и остался
	Ответить | Правка | Наверх | Cообщить модератору

146. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от Анониматор (?), 05-Мрт-25, 10:18
Все языки исчезнут одновременно, как только ИИ заменит кожаных программистов. Ему проще сразу в машинных кодах будет.
Ответить | Правка | Наверх | Cообщить модератору

	175. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (166), 05-Мрт-25, 11:50
	В машинных кодах какой архитектуры? Тогда уж на JS, ну а чего, кросплатформенно же.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (306), 07-Мрт-25, 18:32
	промежуточный код RISC-подобных виртуальных инструкций
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 05-Мрт-25, 14:35
	У ИИ невозможно избавится от галюцинирования из-за самой сути машинного обучения. Вот когда будут разрабатывать сильный ИИ - тогда будет шанс. Но в эту сторону не то что бы шаг сделали - даже голову пока не повернули.
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	196. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (124), 05-Мрт-25, 14:47
	всё будет циклично, сильный ии найдёт лазейку для обучения у более тупого и сам станет тупым
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 06-Мрт-25, 13:40
	> всё будет циклично, сильный ии найдёт лазейку для обучения у более тупого и сам станет тупым Сильный ИИ проверяем. В нем все принятые решения должны быть обоснованы. И эти обоснования можно посмотреть. То есть сильный ИИ должен логически рассуждать. Там нет месту такому обучению, которое используют сейчас.
	Ответить | Правка | Наверх | Cообщить модератору

151. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от Аноним (151), 05-Мрт-25, 10:30
Костыли, костыли, костыли.... К сожалению, костыли.
Ответить | Правка | Наверх | Cообщить модератору

	156. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (118), 05-Мрт-25, 10:35
	руки ноги - это костыли. мозги кстати тоже костыль не очень удачный )))
	Ответить | Правка | Наверх | Cообщить модератору

164. Скрыто модератором	+2 +/–
Сообщение от Аноним (164), 05-Мрт-25, 11:21
Железо памяти никому не позволит сделать её безопасной. Материя первична. Если все возможности наделать ошибок с памятью закрыть, то непременно понадобятся добавки или целые новые языки чтобы их опять открыть. Войнушка раст - плюсы чисто коммерческая. Оба языка синтаксически уродливы. Различие в том что плюсы стали уродом, а раст родился уродом. На этом фоне выиграл питон.
Ответить | Правка | Наверх | Cообщить модератору

	181. Скрыто модератором	+/–
	Сообщение от Аноним (124), 05-Мрт-25, 13:10
	легко. каждому процессу по компу, тогда и памятью делиться не надо
	Ответить | Правка | Наверх | Cообщить модератору

	186. Скрыто модератором	+/–
	Сообщение от Аноним (186), 05-Мрт-25, 13:45
	А какое железо тогда нужно?
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

191. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от Аноним (191), 05-Мрт-25, 14:16
В rust хорошо, там изобретён блок unsafe. А в крестах как они собираются выкурчиваться? Тут же 100% кода как было unsafe, так и осталось, и любой коммит может как улучшить ситуацию, так и ухудшить
Ответить | Правка | Наверх | Cообщить модератору

	192. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (180), 05-Мрт-25, 14:24
	А здесь собираются дать возможность на каждый артефакт навесить что-то типа тега, управляющего функциональностью ему доступной. Помимо опций компиляции. Знает компилятор теги - проверит. Не знает - проигнорирует. Код в любом случае один и тот же.
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (191), 05-Мрт-25, 16:15
	В этом и проблема, что даже если проект и перейдёт на данный вариант, то никаких гарантий, что одним коммитом эту ситуацию не сломают - нет
	Ответить | Правка | Наверх | Cообщить модератору

202. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–3 +/–
Сообщение от fdn721 (ok), 05-Мрт-25, 15:36
Концепция "weak_ptr при захвате превращается в shared_ptr" - редкостное дермицо. Ибо если оригинальный shared_ptr освободит поток владельца, а в это время, weak_ptr будет захвачен, то это передаст владение объектом владельцу weak_ptr. Соответственно из его же потока будет вызван деструктор. По этому weak_ptr не настоящий слабый указать, а всего лишь возможность разорвать циклические ссылки. Как поверх этого дерьма можно ещё какую-то безопасность пытаться накрутить?
Ответить | Правка | Наверх | Cообщить модератору

	218. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (26), 05-Мрт-25, 19:25
	Вы мешаете в кучу теплое и кислое и правильно написали, что weak_ptr и shared_ptr, это только про циклические ссылки. И они не гарантируют корректную работу из разных потоков https://en.cppreference.com/w/cpp/memory/shared_ptr (так же как и попытка разименования nullptr является UB) Поэтому для работы из разных потоков нужно использовать другой класс со встроенной синхронизацией https://github.com/rsashka/memsafe/blob/main/memsafe.h#L416
	Ответить | Правка | Наверх | Cообщить модератору

222. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от Аноним (222), 05-Мрт-25, 20:18
Наконец-то! Можно выбрасывать Java, C#, Golang и начинать всё делать на C++. Это будет также легко и безопасно как на расте! Жду не дождусь. Сейчас вся индустрия повернёт вспять.
Ответить | Правка | Наверх | Cообщить модератору

	223. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+2 +/–
	Сообщение от Аноним (88), 05-Мрт-25, 20:42
	Ну и чего ты здесь опять распетушился со своим растом? Человек хотя бы попробовал - и это похвально. Возможно, кто-нибудь изучит его идеи и придумает что-то ещё более интересное и удобное. Это называется brainstorm.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (26), 05-Мрт-25, 21:03
	>> Возможно, кто-нибудь изучит его идеи и придумает что-то ещё более интересное и удобное. Это называется brainstorm. Именно на это я и надеюсь, так как хоть и пишу на С++ очень давно, но знаю его только в необходимом мне объеме. А чтобы решать подобные глобальные задачи, требуется более  глубокое понимание темы и стандартов, чем у меня.   Я немного обсуждал этот момент с Гербом Саттером и у него бОльший интерес вызвал способ обеспечения обратной совместимости с уже существующим С++ кодом, чем текущая реализация библиотеки (что естественно).
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (274), 06-Мрт-25, 19:41
	С Гербарием не пробовал обсудить?
	Ответить | Правка | Наверх | Cообщить модератору

	313. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (313), 07-Мрт-25, 23:25
	Потому что ненужно. Реально лучше бы раст учили и вливались в современный мир, чем пытаться костыли вкорячивать для легаси технологий. Я вот смотрю как развивается Bevy - ветераны геймдева говорят, что движок *самый* удобный из всех существующих. И с каждой версией становится всё круче, семимильными шагами. Там будущее. Потому, что разрабатывать на нём быстрей и удобней. С момента, когда Карт начал чё-то ваять на коленке прошло 5 лет. Скоро выйдет версия 0.16, в которой рендерилка сравняется с самыми хорошими современными движками. Там будущее, а не в крестах этих гиблых.
	Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

	234. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (191), 06-Мрт-25, 00:31
	Тяжеловесным крестам далеко до выразительных языков. И выборочное решение одной из многих проблем в безопасности не изменит этого
	Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

	236. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от Аноним (217), 06-Мрт-25, 06:09
	Разве С/C++ не являются одними из самых выразительных языков?
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (191), 06-Мрт-25, 12:56
	Нет, не является. В крестах нет очень большого количества возможностей, типа однострочной записи или конвееров.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (306), 07-Мрт-25, 18:35
	this есть. Строй какие хочешь.
	Ответить | Правка | Наверх | Cообщить модератору

235. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от uis (??), 06-Мрт-25, 02:22
> но не требует разработки нового стандарта С++ (достаточно использовать уже существующий С++20). Так-то это уже не стандарт, а расширение языка.
Ответить | Правка | Наверх | Cообщить модератору

270. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
Сообщение от Аноним (306), 06-Мрт-25, 16:14
Авторам: Не соответствие имен переменных в примере и выводе плагина об ошибках vec vs vect x vs beg y vs vect.end()
Ответить | Правка | Наверх | Cообщить модератору

	271. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (26), 06-Мрт-25, 16:20
	Примеры уже поправлены
	Ответить | Правка | Наверх | Cообщить модератору

276. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
Сообщение от Аноним (73), 07-Мрт-25, 00:14
Смысл этой возни с С++ малопонятен - новый код надо писать на Rust, для старого есть CHERI и достаточно пересобрать старый код без переписывания https://cheri-alliance.org/discover-cheri
Ответить | Правка | Наверх | Cообщить модератору

	289. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (287), 07-Мрт-25, 12:52
	Rust конкурент C, а не C++. Это не ООП язык программирования.
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (73), 07-Мрт-25, 13:53
	Когда речь идёт о миллиардных убытках наличие ООП волнует меньше всего - 4 дня на подготовку как в гугле и вперёд фигачить на расте отюда и до заката.
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (306), 07-Мрт-25, 18:38
	Rust между С и С++. Без unsafe ему было бы тяжело выжить.
	Ответить | Правка | К родителю #289 | Наверх | Cообщить модератору

	317. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Tron is Whistling (?), 08-Мрт-25, 09:43
	Вот это вот, не умеющее by design в динамическую линковку без потери своей единственной плюшки - "конкурент C"? Честно - смешно.
	Ответить | Правка | К родителю #289 | Наверх | Cообщить модератору

	318. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от _erthink (?), 08-Мрт-25, 09:46
	Опять сказки про RISCV. Скопипащу про CHERI и оверхед: CHERI во многом похож на безопасный режим Эльбруса. Но в e2k он появился в "железе" на ~20 лет раньше первых черновиков спеки CHERI. Кроме этого, в e2k было несколько редакций, включая поддержку private/public из C++ и т.п. Основная проблема как безопасного режима Эльбруса, так и CHERI, не в оверхеде, а в том что 99% софта нужно переписывать (имеется в виду что смотрим только на релевантный код, а не на питон/bash/java и т.п). В этом, кстати, существенная часть мифа riscv -- на деле вы получаете что-то одно: простоту и дешевизну, производительность, безопасность, но никогда вместе. Особо забавно что часть "экспертов" подразумевают/считают/утверждают, что с CHERI будет также быстро как и без, что будет жрать почти столько-же питания, не сильно дороже, а еще и софт сразу будет совместим ;) > И зачем нести этот оверхед, если... Все всегда будут хотеть снизить накладные расходы и сэкономить на безопасности. Там где безопасность желательна, но не обязательна, вполне логично не только по-полной идти во все тяжкие со спекулятивным выполнением, но даже выбрасывать защиту памяти. Это действительно логично, ведь если у вас весь софт доверенный/отлаженный/проверенный и на условном java/rust, то оставшимися рисками можно пренебречь (например в играх и т.п). А вот там где требуются некие гарантии без аппаратной защиты не обойтись -- там как накладные расходы, так и стоимость соответствующей аппаратуры, принимаются как неизбежное. Это просто ближе большинству сценариев в реальном мире, в том числе потому что невозможно всё нужное/используемое переписать на условных rust/java в разумные сроки. Суммарно рациональнее иметь язык обеспечивающий максимум статических проверок при компиляции и эффективно пользоваться аппаратурой для контроля в runtime, при этом аппаратура может быть как простой, так и обеспечивающей принудительную безопасность. Проблема как языка С, так и "сишного" кода, особенно унаследованного, не в том что он подвержен общеизвестным типам багов, а в том что не позволяет задействовать контролирующую/проверяющую аппаратуру, т.е не совместим ни с безопасным режимом e2k, ни с CHERI. Кстати, поэтому C также является одной из проблем отечественных Эльбрусов. Если помечтать что Linux был-бы написан на условном Rust, то Эльбрусы бы целиком могли работать в безопасном режиме (который тогда можно было-бы допилить/оптимизировать в нужную сторону), а в компиляторе не было-бы EDG-отравы.
	Ответить | Правка | К родителю #276 | Наверх | Cообщить модератору

	319. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (73), 08-Мрт-25, 10:35
	> Основная проблема как безопасного режима Эльбруса, так и CHERI, не в оверхеде, а в том что 99% софта нужно переписывать это проблема Эльбрусов а не CHERI - достаточно ведь погуглить немного https://www.cheribsd.org > 10,000+ pre-built memory-safe packages какое-то портирование нужно конечно но это не переписывание. Основная проблема рассказываетелей мифов про проблемы riscv в том что они живут вчерашним днём где мифические Эльбрусы запретил злой Чубайс напрочь забывая что они просто неконкурентноспособны.
	Ответить | Правка | Наверх | Cообщить модератору

	320. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (320), 08-Мрт-25, 12:17
	> это проблема Эльбрусов а не CHERI - достаточно ведь погуглить немного Достаточно не погуглить, а почитать RTFM, чтобы сделать вывод что CHERI это "рисковый" аналог безопасного режима Эльбруса. Соответственно, для CHERI нужно ровно такое-же "какое-то портирование" как и для Эльбрусов (очевидные и неизбежные различия на уровне инструкций и ассемблера опускаем). Разница только в том "буржуи" вкладывают деньги/ресурсы/усилия в risc5, а "отечественные экспёрты" ноют потому-что пара неудачников на хабре что-то написали... А последствия чубайсятины в развале школы и вышки, до состояния отсутствия стратегического мышления. Поэтому в головы и заходит любой хайп. Поэтому и вредители типа Александра Галицкого (отъявленный лжец и манипулятор, пойманный за язык неоднократно) считаются чуть-ли не пророками. И стеклянные бусы всё еще нравятся.
	Ответить | Правка | Наверх | Cообщить модератору

	321. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (73), 08-Мрт-25, 12:53
	> А последствия чубайсятины в развале школы и вышки, до состояния отсутствия стратегического мышления. стратегическое мышление я так понимаю это отгородиться от мира и идти своим путём не смотря ни на что? Неудивительно что многим с вами не по пути. > Поэтому и вредители типа Александра Галицкого понятия не имею кто это, в идеале нужно разноплановое развитие как в Китае где есть всё - от свое архитектуры до корпусировки и переклеивания шильдиков из вафель брендов
	Ответить | Правка | Наверх | Cообщить модератору

	322. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (320), 08-Мрт-25, 12:56
	> это проблема Эльбрусов а не CHERI - достаточно ведь погуглить немного RTFM "...although CheriABI and Benchmark ABI packages are currently considered experimental." Ну т.е. пакеты собираются, а вот работают только некоторые, и не во всех сценариях, и не всегда, и... Зато можно по примеру упомянутого г-на Галицкого заявлять "это проблема Эльбрусов а не CHERI" и т.п. Тем не менее, если CHERI просто выключить -- то будет чуть более безопасно ;)
	Ответить | Правка | К родителю #319 | Наверх | Cообщить модератору

	323. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от _erthink (?), 08-Мрт-25, 13:07
	> это проблема Эльбрусов а не CHERI - достаточно ведь погуглить немного Как вам уже ответили (Вадим?) проблемы ровно теже, и cheribsd это пока скорее экспериментальный академический pet-проект. Тем не менее, ВСЕ что там будет подготовлено/поправлено/допеределано/отлажено для CHERI подойдет и для Эльбрусов. Причем в 99% не потребует никаких дополнительных доработок, поэтому можно за месяц-два (а может и сильно меньше) превратить cheribsd в e2kbsd.ru Короче, пусть пилят, нам пригодится ;)
	Ответить | Правка | К родителю #319 | Наверх | Cообщить модератору

	330. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (73), 09-Мрт-25, 02:59
	> Причем в 99% не потребует никаких дополнительных доработок, поэтому можно за месяц-два (а может и сильно меньше) превратить cheribsd в e2kbsd.ru на CHERI десктоп с KDE уже год как работает - релиз 24.05, а e2kbsd.ru We’re having trouble finding that site. Похоже никому это не надо.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема