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

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

Сообщения

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

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

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

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

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

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

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

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

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

	29. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (-), 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ообщить модератору

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

	180. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (180), 05-Мрт-25, 13:01
	> Гнилому компилятору гнилые пакеты С чего вдруг? Потому что ты так сказал? Посмотри какие версии gcc новое ядро linux требует. Собирать на всех поддерживаемых дистрибутивах установленными в дистрибутив компиляторами - базовое требование для системных проектов. То что система встройки rust в ядро всегда требует последнюю версию компилятора - это огромная проблема! И она не решаема.
	Ответить | Правка | Наверх | 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 для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Аноним (49), 05-Мрт-25, 05:37
	У моего клиента кучу всего переломали. Use-after-free в сишном демоне, рут шелл, ддос-ферма. Благо мониторинг работает, заметили что начали ноды из сети пропадать и исходящий трафик трендить в лимит, обломали кому-то праздник. Но трафик ещё полбеды, с провайдером всегда можно договориться. Месяц разгребали получившийся в результате бардак, кого-то из отпуска вызвали, каким-то кастомерам сроки сорвали, и у них что-то следом посыпалось, в целом нервная атмосфера — вот это реально дорого вышло. То, что вас весь бизнес — это лендинг на народе.ру и сеточка 192.168.0.0/24 не значит, что у всех так.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

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

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

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

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

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

	10. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+1 +/–
	Сообщение от 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ообщить модератору

	14. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–7 +/–
	Сообщение от НяшМяш (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 для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Карлос Сношайтилис (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ообщить модератору

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

	101. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	–1 +/–
	Сообщение от Карлос Сношайтилис (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ообщить модератору

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

	225. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (225), 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. "Релиз проекта Memsafe для безопасной работы с памятью в С++"	+/–
	Сообщение от Аноним (225), 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ообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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