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

"C++ Alliance продвигает в C++ механизмы безопасной работы с памятью, опробованные в Rust"	+/–
Сообщение от opennews (??), 17-Сен-24, 14:41
Президент организации C++ Alliance объявил о  работе над спецификацией, добавляющей в язык C++ расширения для безопасной работы с памятью, напоминающих возможности, реализованные в языке Rust. Для осуществления проекта привлечён Шон Бакстер (Sean Baxter), автор экспериментального C++-компилятора Circle, развивающего идеи по повышению безопасности кода C++, реализуемые  на стороне компилятора без использования сборки мусора. В рамках проекта Шон опубликовал документ с анализом применимости тех или иных мер защиты, предлагаемых в языке Rust, оценкой возможности их реализации для C++ и предложениями по добавлению в язык C++ расширений, повышающих безопасность кода... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61878
Ответить | Правка | Cообщить модератору

Сообщения

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

2. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+9 +/–
Сообщение от Минона (ok), 17-Сен-24, 14:42
> C++-компилятора Circle Убийца Rust № 1. Кто следующий?
Ответить | Правка | Наверх | Cообщить модератору

	89. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (89), 17-Сен-24, 17:08
	Если в какой-нибудь C++2next примут, то все компиляторы станут убиийцами.
	Ответить | Правка | Наверх | Cообщить модератору

4. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+6 +/–
Сообщение от Аноним (4), 17-Сен-24, 14:43
+100500% compilation times?
Ответить | Правка | Наверх | Cообщить модератору

	91. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+10 +/–
	Сообщение от Аноним (89), 17-Сен-24, 17:12
	Ради такого дела и дела вытеснения Rust стоит подождать. Это лучше, чем +90 Gb для сборки Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+10 +/–
	Сообщение от Аноним (99), 17-Сен-24, 17:33
	> Это лучше, чем +90 Gb для сборки Rust. А почему не 900 Gb? Слабенько набрасываешь...
	Ответить | Правка | Наверх | Cообщить модератору

	175. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 17-Сен-24, 21:17
	>Это лучше, чем +90 Gb для сборки Rust. А зачем вы его пересобираете?
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	213. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Прохожий (??), 18-Сен-24, 01:45
	Как-то время скоротать, например. Видимо, других, более полезных занятий не нашлось.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (250), 18-Сен-24, 09:15
	Чтобы пересобирать, надо для начала хотя бы собрать.
	Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

	262. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от that is not this (?), 18-Сен-24, 09:43
	beyond from beyond from rust
	Ответить | Правка | Наверх | Cообщить модератору

	310. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (310), 18-Сен-24, 17:27
	Бинарный кеш в ваших репах не изобретён?
	Ответить | Правка | К родителю #250 | Наверх | Cообщить модератору

	123. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (123), 17-Сен-24, 18:35
	Так-то и Раст довольно медленно компилиться, медленнее С++
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–2 +/–
Сообщение от Аноним (5), 17-Сен-24, 14:43
Ёж++ птица гордая... Но лучше поздно, чем никогда. Ещё бы модули везде были.
Ответить | Правка | Наверх | Cообщить модератору

	31. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–8 +/–
	Сообщение от Fjyj (-), 17-Сен-24, 15:31
	Так боюсь уже поздно. Просто представь новичков, которые ищут "а какой язык стоит учить?". Если они поумнее и не хотят идти в вебкамаки на всяки JS/TS, то выбора из современных у них не так уж много. Если мобилки - то swift/kotlin,  ну и всякие флаттеры. Если серваки то там гошка и прочая вебня. Если хочеться в геймдев (с кранчами по 80 часов) - С++. Но не факт, что там будет это новый C++ Circle. Значит или учить оба или выбирать. Чистую СИшку учить может только любитель всяких некропрограмм и легаси. Т.к даже под микроконтролееры можно писать и на плюсах и на расте. Когда это примут, будет ли оно частью стандарта или просто сбоку прилеплено.. А тут уже есть Rust, который добавляют в ядро, на котором уже пишут проекты и даже ОС. Выбор кажется очевидным.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+4 +/–
	Сообщение от Аноним (39), 17-Сен-24, 15:40
	> Если хочеться в геймдев (с кранчами по 80 часов) - С++. Но не факт, что там будет это новый C++ Circle. В геймдеве в гробу видали как новые стандарты C++, так и стандартную библиотеку полюсов.  А на вопросы безопасности там и подавно наплевать.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Александр (??), 17-Сен-24, 19:25
	Ну, не то, что бы видали. Сам из геймдева. Стандартную библиотеку используем, ибо со своими граблями проблем больше. На соседнем проекте своя, но там исторически сложилось: игре порядка 15 лет, ещё под симбианы выпускалась. Да и то пытаются отвинтить. Что касается новых стандартов, это похоже у всех в плюсах. И дело не в том, что не нужно, а в том, что: 1. Свежие стандарты сырые. Минимум следующий жди. 2. Не очень поддержка (в пример модули те же). 3. Переход бывает затратен без особого профита.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от n00by (ok), 18-Сен-24, 09:36
	> В геймдеве в гробу видали как новые стандарты C++, так и стандартную > библиотеку полюсов. EASTL stands for Electronic Arts Standard Template Library. It is a C++ template library of containers, algorithms, and iterators useful for runtime and tool development across multiple platforms. It is a fairly extensive and robust implementation of such a library and has an emphasis on high performance above all other considerations. https://github.com/electronicarts/EASTL
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	66. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+4 +/–
	Сообщение от Аноним (66), 17-Сен-24, 16:10
	> Т.к даже под микроконтролееры можно писать и на плюсах и на расте Так можно хоть на луа писать, вот только пишут все равно на сишке.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	93. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–4 +/–
	Сообщение от Аноним (-), 17-Сен-24, 17:18
	Естественно. У нас есть целые поколения покалеченные сишкой.. на чем им еще писать? Когда тебе просто плевать на надежность кода и ты как "самые лучшие инжинеры тойоты" просто ребутаешь микроконтролер в случае ошибки,  то можно и на дыряшке писать. А если нет, то испольузется Ada/SPARK. Сейчас к этому списку может добавиться раст.
	Ответить | Правка | Наверх | Cообщить модератору

	267. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от cr (??), 18-Сен-24, 10:04
	что вы носитесь из темы в тему с этой тоётой? какбудто она единственная кто пишит МК на сях, а остальные на божественном^W расте^W хз чём. в чём язык виноват, если тоёта набрала чудаков
	Ответить | Правка | Наверх | Cообщить модератору

	94. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (89), 17-Сен-24, 17:18
	>Так боюсь уже поздно. Не поздно. Тот пресловутый корован, который, как бы, идёт, но только всё ещё больше лает, чем идёт.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	103. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–3 +/–
	Сообщение от Аноним (103), 17-Сен-24, 17:54
	> Не поздно. Тот пресловутый корован, который, как бы, идёт, но только всё ещё больше лает, чем идёт. А ты думал будет легко? Что авгиевые конюшни овнокода разгребутся на раз-ва? Что диды неосиляторы, которые одной ногой в маразме, скажут "да, конечно, я готов учить что-то новое"? Хаха, тогда твоя наивность просто необъятная. Естественно копротивеление будет максимальное. Понятно что старички будут держаться за насиженные теплые местечки и делать себе job safety любыми способами. И у меня очень большие сомнения, что в ядре будет успех. Но это не значит, что не нужно было пробовать. Вот коммитет С++ о чем-то тоже задумался
	Ответить | Правка | Наверх | Cообщить модератору

	109. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (109), 17-Сен-24, 18:05
	> "да, конечно, я готов учить что-то новое" как в анекдоте про байкеров "вы каждый год новые". Диды просто видят, что не осилят и свою работу и переписывание и видят, что осиляторов полным-полно
	Ответить | Правка | Наверх | Cообщить модератору

	119. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (-), 17-Сен-24, 18:23
	> как в анекдоте про байкеров "вы каждый год новые". Угу, думаю конюхи точно так же думали про эти ваши новомодные тарахтелки. Мало того что жужжит, так еще и топливо в аптеке покупать нужно, оно воняет.. не то что родной конский навоз! > Диды просто видят, что не осилят и свою работу и переписывание и видят, что осиляторов полным-полно Да, по кол-ву CVE видно как диды осиливают свою работу. Бедняга Линус ноет что за 33 года (наверное на печи лежали) не осилили даже базовый менеджмент памяти: "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."
	Ответить | Правка | Наверх | Cообщить модератору

	160. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (109), 17-Сен-24, 20:20
	> Угу, думаю конюхи точно так же думали про эти ваши новомодные тарахтелки. А тарахтелки тоже появились сразу в неограниченном количестве? А новые типы тарахтелок с измененным интерфейсом "конюха" как часто появляются? А тарахтелки уже имеют конструкционные зависимости от других тарахтелок? > Да, по кол-ву CVE видно как диды осиливают свою работу. да я уже понял, что диды плохие. Я не понял, почему они должны что-то осиливать в отношении раста. Вообще не понимаю зачем чего-то требовать от плохих дидов, если можно сделать хорошо. Сделаете хорошо -- диды останутся без работы и им придется выучить раст
	Ответить | Правка | Наверх | Cообщить модератору

	204. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от RM (ok), 18-Сен-24, 01:02
	> "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management." Сдается мне что это не про аллокатор, а про 12309 и обработку oom.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	132. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от _ (??), 17-Сен-24, 19:00
	Хороший анекдот! Таки надо рассказать Сонечке (С)
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	145. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Александр (??), 17-Сен-24, 19:31
	Проблема не в осиляторстве. Проблема в том, что за это осиляторство платить никто не будет. Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок. Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечивать. Плюс пайплайн сборки курочить. На это добрый мес уйти может вполне, а за чей счёт?
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	167. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 20:32
	> Проблема не в осиляторстве. Проблема в том, что за это осиляторство платить никто не будет. Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок. Просто так, ради искусства? Не, тогда не имеет смысла. Или у нас просто куча багов, и пограммисты сидят днями раcковыривая очередной SIGABRT. Их зарплату тоже нужно учитывать. Добавь сверху репутационные потери, например от порчи юзерских данных. (Опенсорс проекты это не касается, тут народ привык "жрать чо дали" главное открыто и бесплатно). А может еще штраф за утечку прилетит.. это у нас 40к рублей, а по GDPR может и 4% годового дохода. С этой точки уже не так и дорого может получится. > Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечивать. Плюс пайплайн сборки курочить. На это добрый мес уйти может вполне, а за чей счёт? Естественно за свой. Вопрос что будет выгоднее, постоянно тратить деньги на заплатки и затыкание дыр. Или переделать старое. Особенно если достаточно сделать обертки и переписать самые стремные места.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (109), 17-Сен-24, 23:50
	> Или у нас просто куча багов, и пограммисты сидят днями раcковыривая очередной SIGABRT. только проблема в том, что куча багов у нас уже есть и теперь нужны еще программисты чтобы переписывать все. Их зарплату тоже нужно учитывать. А новые программисты нужны потому что > Добавь сверху репутационные потери, из-за репутационных потерь мы не можем не фиксить ту кучу багов, что уже есть. И не выкатывать новые фичи, мы тоже не можем (хотя может и можем ограничить их количество) А потом новый код надо будет еще усиленно тестировать, чтобы не появилось еще больше репутационных потерь. > Вопрос что будет выгоднее, постоянно тратить деньги на заплатки и затыкание дыр. там еще вопрос, как потом жить с тем, что переписали. В погоне за переписыванием можно получить кадавра, в которого уже ничего нового нормально не добавить > Особенно если достаточно сделать обертки и переписать самые стремные места. и посчитать как эти обертки повлияют на производительность
	Ответить | Правка | Наверх | Cообщить модератору

	244. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 18-Сен-24, 08:56
	> только проблема в том, что куча багов у нас уже есть и На божественной сишечке куча багов? А не еретик ли ты))? Но даже если эта куча есть, а вы еще не разорились.. то значит пользователи привыкли. > теперь нужны еще программисты чтобы переписывать все. Выдели одного-двух, пусть работают по принципу парето и закрывают самые опасные участки кода > из-за репутационных потерь мы не можем не фиксить ту кучу багов, что уже есть. И не выкатывать новые фичи, мы тоже не можем (хотя может и можем ограничить их количество) Ты что взял и всю команду перекинул напереписывание? Но зачем? У вас должен быть какой-то запас по капасити. В крайнем случае, не все фичи одинаково полезны, и минорные низко-приоритетные можно отложить. > А потом новый код надо будет еще усиленно тестировать, чтобы не появилось еще больше репутационных потерь. Судя по огромной куче багов - вы его вообще не тестируете. Так что особо ничего не поменятся. > там еще вопрос, как потом жить с тем, что переписали. А как люди живут, когда в проекте одновременно C, C++, Java и Kotlin? (Это реальный пример - андроид). Вот гугловцы новый код пишут на Расте, вот с таким результатом "To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html > В погоне за переписыванием можно получить кадавра, в которого уже ничего нового нормально не добавить Ну так делай нормально, нормально и будет. > и посчитать как эти обертки повлияют на производительность Никак. Уже считали, там на уровне погрешности измерений.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (109), 18-Сен-24, 10:05
	> На божественной сишечке куча багов? А не еретик ли ты))? так вроде никто не утверждал, что на божественной сишечке не делают логических ошибок > Выдели одного-двух, пусть работают по принципу парето и закрывают самые опасные участки кода ну то есть сделать как было в ядре. Там как раз было трое, но один уже не смог переписывать обвязки для раста с нужной скоростью > Ты что взял и всю команду перекинул напереписывание? а мы про какой проект говорим? Про такой, где тысячи разработчиков и 1-2 будут переписывать долго и печально или про такой, где всего 1-2 разработчика? > У вас должен быть какой-то запас по капасити. кому должен? У нас с тем кому должен товарно-денежные отношения? > Судя по огромной куче багов - вы его вообще не тестируете. тогда смысл от переписывания? > А как люди живут, когда в проекте одновременно C, C++, Java и Kotlin? там следующее предложение продолжает мысль. Зачем отвечать на часть мысли? > Ну так делай нормально, нормально и будет. а при чем тут раст? > Уже считали, там на уровне погрешности измерений. дай ссылку на исследование
	Ответить | Правка | Наверх | Cообщить модератору

	275. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 18-Сен-24, 10:46
	> так вроде никто не утверждал, что на божественной сишечке не делают логических ошибок Так проблема не в логических ошибках. Против них реально работает только формальная верификация - но это просто тонны денег. > ну то есть сделать как было в ядре. Там как раз было трое, но один уже не смог переписывать обвязки для раста с нужной скоростью И в итоге ядро как было дырявым, так и осталось. У нас же нет времени подождать, нам надо CVE плодить. > а мы про какой проект говорим? про твой в 500k loc'ов > Про такой, где тысячи разработчиков и 1-2 будут переписывать долго и печально или про такой, где всего 1-2 разработчика? У тебя 1-2 тащат такой проект в одиночку? Я им слегка сочувствую. > кому должен? У нас с тем кому должен товарно-денежные отношения? Себе хотя бы) Ну чтобы если вдруг заболел или вдруг второго разработчика сбил автобус, то не было просранных сроков. Но если ты про опенсорс, то да, тут всем плевать на сроки, приоритезацию, планирование. Как-то оно катится и пусть катится. > тогда смысл от переписывания? Чтобы багов стало меньше) Можно же переписывая часть багов исправить. >> Ну так делай нормально, нормально и будет. > а при чем тут раст? Потому что ни на плюсах, ни на дыряшке уже пол века не выходит. >> Уже считали, там на уровне погрешности измерений. > дай ссылку на исследование можешь посмотреть бенчи benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html
	Ответить | Правка | Наверх | Cообщить модератору

	296. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (109), 18-Сен-24, 16:23
	> Так проблема не в логических ошибках. Проблема, что их тоже надо исправлять Но это не я еретиков каких-то рассмотрел > И в итоге ядро как было дырявым, так и осталось. > У нас же нет времени подождать, нам надо CVE плодить. так а сколько ждать? В комментариях какие-то абстрактные требования и судя по всему в обычной манере "нужно вчера" Как потребитель — я железки купил и мне нужна поддержка в ядре, а не ждать когда кто-то что-то перепишет. Как разработчик — конкуренты тоже подождут? > У тебя 1-2 тащат такой проект в одиночку? Я им слегка сочувствую. это не я предложил выделить 1-2 на переписывание без обсуждения сложности проекта > Себе хотя бы) себе я не должен работы, на которую нет спроса и которая не оплачивается. Личные проектики — если он вдруг кому-то внезапно понадобилось (и они это как-то нашли), то сами перепишут, проекты конторы — контора не заинтересована. > Чтобы багов стало меньше) > Можно же переписывая часть багов исправить. или наоборот добавить, гарантий никто не дает > Потому что ни на плюсах, ни на дыряшке уже пол века не выходит. так и причем тут раст? Судя по статьям, на раст выходит сильно по разному > можешь посмотреть бенчи там нет бенчмарков гипотетических оберток в гипотетическом проекте, гипотетически переписывываемом на раст Вспомнил как "переписали" ioquake на раст, почти пять лет прошло. Я тогда почти поверил
	Ответить | Правка | Наверх | Cообщить модератору

	207. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Александр (??), 18-Сен-24, 01:07
	Не знаю, как там на сях, у нас sigabrt 2-5 раз в год (по большей части либо в древнем C-style коде, либо в рендере OpenGL, где из-за критичности к скорости на расте скорее всего влепили бы unsafe). При этом гораздо больше проблем бывает с use after free на пуле (раст такое ловить не сможет скорее всего), когда нужно втыкать, какие переменные должны уйти в пул, а какие нет; анимациями, развалом контента. То есть, то, где раст мимо. И таким образом, ради пары багов год (по 2-4ч на каждый) должны потратить от мес до пары лет, дабы переплыть на раст? > порчу юзерских данных Клиент мобильной MMO RPG. Не знаю, что там испортить можно. Да и по sigabrt данные скорее всего не запортишь. Быстрее другими багами (копипастой например). > GDPR Снова мимо: данные на сервере. Он на шарпах. > естественно за свой То есть мне, как программисту, предлагаете сидеть вместо 8 часов все 24 часа в сутки и отверженно переводить проект на раст?) Если для вас это норм, вы мазохист. > самые стрёмные места Не менее 30% проекта
	Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

	188. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 17-Сен-24, 22:41
	>Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок. Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечивать Нужно переписывать плавно и неспеша. https://habr.com/ru/articles/511478/ >На это добрый мес уйти может вполне, а за чей счёт? Не важно. Поскольку функционал перетекает плавно, можно хоть десять лет делать. А делается это за счёт тех, кому данный проект нужен.
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	211. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Александр (??), 18-Сен-24, 01:13
	> Нужно переписывать плавно и неспеша. Статья про си. С плюсовым такое не проканает: минимальная переписываемая единица будет класс, да и то не всегда, если он покрыт шаблонной магией. А это от дня до недели разработки + тестирование > А делается это за счёт тех, кому данный проект нужен Им нужен проект и деньги с него, а не защита от каких-то мифических багов
	Ответить | Правка | Наверх | Cообщить модератору

	194. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+4 +/–
	Сообщение от adolfus (ok), 17-Сен-24, 23:19
	Есть проект на коболе. Сколько нужно заплатить, чтобы переписать его на <...>? Есть проект на фортране. Сколько нужно заплатить, чтобы переписать его на <...>? Так вот, никто никому ничего платить не будет, поскольку все написанное на "опасных", бл..ть, для тупых программиздовъ языках, работает без осечек. Пример: "дид" Д. Кнут xep знает когда написал TeX. Одна из тех программ, которые не нуждаются в постояном дописывании/переписывании. И никаких проблем с выделением/освобождением памяти и выходом за какие-то пределы там не наблюдается. Может просто признать, что 99% так называемых "программистов" тупые дoлбойoбы, не способные без сработавшего UB даже helloword написать.
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	241. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (241), 18-Сен-24, 08:33
	> Может просто признать, что 99% так называемых "программистов" тупые дoлбойoбы, не способные без сработавшего UB даже helloword написать. О, ну это классика. "Зачем вы пишете с багами? Просто пишите без багов!".
	Ответить | Правка | Наверх | Cообщить модератору

	242. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 18-Сен-24, 08:44
	> работает без осечек. Только если это хеллоуволрд) Посмотри на ядро где менеджмент памяти до сих пор с базовыми ошибками, по мнению Торвальдса. Или на ХОрг - просто куча овнокода, где ошибки живут по 30 лет. > Одна из тех программ, которые не нуждаются в постояном дописывании/переписывании. И никаких проблем с выделением/освобождением памяти и выходом за какие-то пределы там не наблюдается. Отлично! Нам повезло и у нас есть одна программа, которая не подарит рут, когда ты в нее напишешь 28 бекспейсов! > не способные без сработавшего UB даже helloword написать. Что значит "сработавшего UB"? UB оно или есть, или нету. Причем что в дыряшке, что в плюсах int a + int b - это уже UB! И по стандарту, результирующий код уже не strictly conforming. Так что удачи тебе написать helloword, без UB. Спасибо качественному "стандарту"))
	Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

	176. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Диды (?), 17-Сен-24, 21:21
	>Что диды неосиляторы, которые одной ногой в маразме Как же вы задрали! Всё что есть в индустрии - это написали мы, диды. Пишем как считаем нужным и указывалка ещё у вашего поколения не выросла
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	190. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 17-Сен-24, 22:45
	>Всё что есть в индустрии - это написали мы, диды. Спасибо, диды, за IE 6, сам по себе такой бы монстр не появился. А ведь сколько подобных монстров диды насоздавали: SysVinit, bash, perl, make, autotools и куча прочего. До сих пор от всего не избавились.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (111), 17-Сен-24, 18:06
	> Чистую СИшку учить может только любитель всяких некропрограмм и легаси. > Т.к даже под микроконтролееры можно писать и на плюсах и на расте. Можно. Но... 1) На сях вы будете выдавать продуктивный результат сильно быстрее чем на вон тех кошмариках. 2) safety critical и прочие требовательные штуки на сях - тупо проще и быстрее, из-за педальности его окружения и минимализма рантайма, особенно ежели без stdlib'а. А про C++ хорошо написали в книжке "Scalable C". И хотя это весьма biased и специфичное чтиво от автора ZMQ - но плюсам оно наподдает весьма за дело. Все перечисленные проблемы я там видел лично. В том числе и уход кодеров в астрал^W использование своего субдиалекта, а потом... потом... потом этот код майнтайнить никто не может и наступает - ж@па! То что делает 1 кодера мощнее не обязательно что круто при командной игре.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	114. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 18:12
	> safety critical и прочие требовательные штуки на сях - тупо проще и быстрее Слава богу, в safety critical сишку чаще всего не подпускают на пушечный выстрел. Иначе бы был целый самолетопад. А где пускают - то там всякие мисры, которые к си отношения практически не имеют, один синтаксис общий. > использование своего субдиалекта Не хуже чем написание своих велосипедов на си, когда чего-то не находится в стандартной либе. Вон недавно свой сплит писали... и дописались до CVE.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 18:16
	> Можно. Но... > 1) На сях вы будете выдавать продуктивный результат сильно быстрее чем на вон тех кошмариках. Что такое "продуктивный результат"? Если х-к-х-к и в продакшн, то да. > 2) safety critical и прочие требовательные штуки на сях - тупо проще и быстрее, из-за педальности его окружения и минимализма рантайма, особенно ежели без stdlib'а. Но почему-то все равно пишут на ADA/Spark)) Потому что убогость в которой дыреней больше чем в швейцарском сыре, нужна только там где другого не знают. Вот появится там хотя бы defer из коробки, тогда мождно будет говорить)) > А про C++ хорошо написали в книжке "Scalable C". И хотя это весьма biased и специфичное чтиво от автора ZMQ - но плюсам оно наподдает весьма за дело. Так biased или за дело? Если у тебя какая-то сложнейшая задача - например писать в одну и ту же память одновременно с кучи потоков... Но везде ли есть такое? > Все перечисленные проблемы я там видел лично. В том числе и уход кодеров в астрал^W использование своего субдиалекта, а потом... потом... потом этот код майнтайнить никто не может  и наступает - ж@па! То что делает 1 кодера мощнее не обязательно что круто при командной игре. Ой, а типа у нас в ядре не свои гнутые экстеншины? И 20 лет вендорлока на один раковый компилятор? Ты ж понимаешь, что на любом языке можно сделать свой диалект, хоть на СИ, хоть на JS. Накрутить абстракций или сложных алгоритмов.. Ну чтобы быть незаменимым. Т.к мы говорим про микроконтролеры, то думаю ты в курсе про Тойоту и их "шЫдевр". Функция с цикломатикой в 150. На такое мало кто способен.
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	147. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Bottle (?), 17-Сен-24, 19:38
	Чел, этот миф про субдиалект уже всем порядком надоел. В любом тьюринг-полном языке можно выработать свой особый стиль написания кода. Си, к слову, ещё хуже, так как то, что решается из коробки плюсовыми шаблонами и consteval'ом, решается в Си через такой жуткий костыль как макросы, и то не полностью.
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	143. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Александр (??), 17-Сен-24, 19:27
	С МК у раста пока не шибко хорошо. Какие-нибудь arm - норм, а вот тот же avr, на сколько знаю, ещё в третьей стадии поддержки
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	159. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 20:16
	> С МК у раста пока не шибко хорошо. Какие-нибудь arm - норм, > а вот тот же avr, на сколько знаю, ещё в третьей стадии поддержки Вообще не вижу смысла в avr для новых проектов. Вот совсем. Для новых есть сотни вариантов stm32, причем младшие дешевле avr и производительнее. Есть прочие ARMы, есть ESP32, есть еще куча других. А старые никто переписывать не будет. Но если вы в теме, может опровергнете такое мнение.
	Ответить | Правка | Наверх | Cообщить модератору

	302. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от 1 (??), 18-Сен-24, 17:01
	> Выбор кажется очевидным. JAVA ?
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

6. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+10 +/–
Сообщение от 13 (??), 17-Сен-24, 14:44
> растущую в среде разработчиков потребность в безопасных методах программирования Эталонная подмена понятий. Браво.
Ответить | Правка | Наверх | Cообщить модератору

	34. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (39), 17-Сен-24, 15:34
	Какие именно понятия тут подменили?
	Ответить | Правка | Наверх | Cообщить модератору

	40. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от Хру (?), 17-Сен-24, 15:41
	Подмена в том, что это не разработчикам, а крупным клиентам корпооаций надо (и самим корпам!) Ну а разрабы 99% работают "на отъе..сь", ну а конечным покупателям кто ж обеспечит безопасность за те копейки, которые они платят?..
	Ответить | Правка | Наверх | Cообщить модератору

	46. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–3 +/–
	Сообщение от Аноним (39), 17-Сен-24, 15:53
	> Подмена в том, что это не разработчикам, а крупным клиентам корпооаций надо (и самим корпам!) А ты в курсе, что разработчики - это работники тех самых корпораций? И задача  их буквально состоит в решении проблем корпораций.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–3 +/–
	Сообщение от Аноним (85), 17-Сен-24, 17:05
	зачем ему на такие мелочи обращать внимание. он отважный диванный борец с корпорациями, четкий бородатый админ на бюджете. его красные глаза наполняются слезами, когда видят как злобные корпы угнетают все открытое и доброе
	Ответить | Правка | Наверх | Cообщить модератору

	58. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от Анонимусс (-), 17-Сен-24, 16:03
	Оно скорее больше юзерам нужно, а не разрабам. Потому что их задобало, что им могут ломануть напр. телегу или фейсбучек просто прислав картинку. Ну а какой умелец в либе разбора не проверил входные данные и всё - кровь, кишки... А юзеры в свою очередь делают дырку в голове корпам, предоставляющим сервис... Да и просто новости про дыры хорошо тиражируются журналистами и немного портят настроение совету директоров)))
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	124. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (89), 17-Сен-24, 18:37
	> Потому что их задобало, что им могут ломануть напр. телегу или фейсбучек Ломануть Фейсбучек - смишно. Те, "кому положено" и "там разберутся", в Фейсбучеках и без взломов пасутся.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Анонимусс (-), 17-Сен-24, 20:01
	> Те, "кому положено" и "там разберутся", в Фейсбучеках и без взломов пасутся. Да. У них есть если не прямой доступ, то доступ по запросу "выгрузите мне все". И с этим ты ничего не сделаешь. Но речь не про них. А про угоны самих учеток для рассылки спама и просьб "дай 2000 до следующей зп". Про майнеров, который через браузер пролазят, про шифровальщиков, про скраперы банковких данных и тд. Сейчас это все чуток сложнее стало делать, обновлением флешплеера не отделаешься. А вот регулярные дыры очень помогают.
	Ответить | Правка | Наверх | Cообщить модератору

7. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–3 +/–
Сообщение от Аноним (7), 17-Сен-24, 14:45
В C++ первым делом нужно добавить стандартные профили, ограничивающие некоторые возможности языка (вроде арифметических операций с указателями или вообще доступность указателей как таковых) по требованию и более полно определяющие поведение в различных ситуациях.
Ответить | Правка | Наверх | Cообщить модератору

	23. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+9 +/–
	Сообщение от Аноним (-), 17-Сен-24, 15:10
	> и более полно определяющие поведение в различных ситуациях. Может ты еще и UB предложишь убрать?? На последние скрепы решил покуситься?! На костер еретика!
	Ответить | Правка | Наверх | Cообщить модератору

	314. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 17:42
	Нет стандарта - нет UB.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от slavanap (?), 17-Сен-24, 20:04
	Так это уже можно сделать. Определить шаблоны, перекрывающии такие операции, но без реализации или со static_assert(false) и линковка/компиляция начнёт падать. Тут, скорей, проблемы не только в указателях, но и в ссылках на объекты, у которых может истечь время жизни раньше разрушения объекта с ссылкой.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	161. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от Аноним (161), 17-Сен-24, 20:21
	С любыми этими профилями это уже будет не C++. Делайте свой язык, а там видно будет.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	313. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 17:39
	Если это будет строгое подмножество, то это все еще C++.
	Ответить | Правка | Наверх | Cообщить модератору

8. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
Сообщение от Аноним (8), 17-Сен-24, 14:48
Вот только это уже будет не С++, сломается обратная совместимость, деды и тут будут недовольны.
Ответить | Правка | Наверх | Cообщить модератору

	50. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от Аноним (50), 17-Сен-24, 15:58
	Гы, считай что в каждом стандарте плюсов есть "Removed and deprecated". Для примера: C++20: Use of comma operator in subscript expressions has been deprecated C++23: Use of comma operator in subscript expressions was no longer deprecated but the semantics has been changed to support overloadable n-adic operator[]
	Ответить | Правка | Наверх | Cообщить модератору

	83. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Bottle (?), 17-Сен-24, 16:56
	Да пох на этих дедов, ни один компилятор не соответствует стандарту на 100%, а значит, в общем случае невозможно написать корректный кроссплатформенный код. Либо корректный, либо кроссплатформенный (и то второе не гарантируется).
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	113. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (-), 17-Сен-24, 18:09
	> Вот только это уже будет не С++, сломается обратная совместимость, деды и > тут будут недовольны. Ну так пусть и компилят под свой замшелый стандарт типа CPP98, никто ж не запрещает! ;). Просто придется сказать "проект юзает C++98". А не C++23 или сколько там.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	117. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 18:19
	> Ну так пусть и компилят под свой замшелый стандарт типа CPP98, никто ж не запрещает! ;). Ты тут такого не говори (с) > Просто придется сказать "проект юзает C++98". А не C++23 или сколько там. Нытье и вой будет.. до небес) Понятно что обратная совместимость это хорошо, но меру надо знать. А у комитетчиков (что СИ, что плюсы) ее нету. Так и будут тянуть поддержку инструкций для всяких допотопных архитектур "а вдруг кто-то найдет на складе 100500 миллионов 8008"
	Ответить | Правка | Наверх | Cообщить модератору

	129. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (129), 17-Сен-24, 18:53
	> сломается обратная совместимость Каким образом, если проверка только на стороне комрилятора?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	133. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (-), 17-Сен-24, 19:00
	>> сломается обратная совместимость > Каким образом, если проверка только на стороне комрилятора? Не знаю. Но разработчики стандарта такие затейники, что думаю что-то придумают. Например в C23 они поменяли zero-sized reallocations with realloc are undefined behavior. Т.е был валидный код void *ptr = malloc(0); free(ptr); а вот void *ptr = malloc(4096); ptr = realloc(ptr, 0); уже UB на откуп разработчикам компилятора.
	Ответить | Правка | Наверх | Cообщить модератору

10. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+6 +/–
Сообщение от Аноним (10), 17-Сен-24, 14:51
Порог входа неуклонно растёт, а количество полностью знающих язык и его стандартную библиотеку падает.
Ответить | Правка | Наверх | Cообщить модератору

	60. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (60), 17-Сен-24, 16:05
	неправда, книги как были около 1300 страниц в 2003, так и остались по с++23
	Ответить | Правка | Наверх | Cообщить модератору

	67. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (66), 17-Сен-24, 16:12
	> книги как были около 1300 страниц в 2003 Так ты забыл умножить количество страниц на количество стандартов. В новых книгах и акцент на новом.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от 12yoexpert (ok), 17-Сен-24, 17:54
	ну так а нефиг в 2024 писать while(*dst++=*src++)
	Ответить | Правка | Наверх | Cообщить модератору

	107. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (107), 17-Сен-24, 18:04
	Только что писал для выноса анимации в вебе на C/WASM. Видишь ли libc чтобы дёрнуть memcpy нет в среде исполнения Wasm.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–2 +/–
	Сообщение от Аноним (-), 17-Сен-24, 17:07
	Как правильно заметил анон выше - умножь на количество стандартов. А потом еще умножь на количество самых распространенных компиляторов. Ну чтобы не сесть в лужу, когда делаешь простейши действия.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	259. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от n00by (ok), 18-Сен-24, 09:40
	N4860 - 1829 страниц.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	86. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Bottle (?), 17-Сен-24, 17:05
	Это нормально. Со временем комитет осознаёт, какие вещи наиболее востребованы среди программистов и стандартизирует подход.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	95. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (95), 17-Сен-24, 17:21
	> Со временем комитет осознаёт, какие вещи наиболее востребованы среди программистов и стандартизирует подход. Для стандартизации подхода нужно будет создавать отдельный коммитет или можно использовать текущий? Нужна ли стандартизация подходов стандартизации? Может ли случиться рекурсивное создание коммитетов или уход текущего в бесконечный цикл? Столько вопросов на которые нет ответов (((
	Ответить | Правка | Наверх | Cообщить модератору

	90. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (123), 17-Сен-24, 17:08
	Другие языки тоже обрастают фичами. Я думаю, немногие питонисты или яваскриптчики знают вот прямо абсолютно все фичи Питона или Яваскрипта. > стандартную библиотеку Стандартная библиотека Явы гораздо больше, чем у С++, все её уголки тем более никто не знает. Однако же пишут как-то на Яве. :)
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	149. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Bottle (?), 17-Сен-24, 19:40
	Даже более того, её кто-то да знает. Например, сами разработчики из Oracle.
	Ответить | Правка | Наверх | Cообщить модератору

	228. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (228), 18-Сен-24, 06:53
	Имеется ввиду, что ни один человек её целиком от и до не знает. Разумеется эти знания размазаны по большому числу людей...
	Ответить | Правка | Наверх | Cообщить модератору

	247. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Писатель (?), 18-Сен-24, 09:09
	> Стандартная библиотека Явы [ ... ], все её уголки тем более никто не знает - JavaDoc? - Не-е ... Не слышали ...
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	274. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (274), 18-Сен-24, 10:45
	И Doxygen, ага. Что сказать-то хотел?
	Ответить | Правка | Наверх | Cообщить модератору

11. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от Аноним (7), 17-Сен-24, 14:55
Был проект по добавлению аннотаций времени жизни в Clang C++, но почему-то сдулся: https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/...
Ответить | Правка | Наверх | Cообщить модератору

12. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–3 +/–
Сообщение от Rev (ok), 17-Сен-24, 15:00
Какой только хернёй они не занимаются, чтобы только не переходить на Раст... Не получится навязать готовому языку безопасность в виде костылей.
Ответить | Правка | Наверх | Cообщить модератору

	25. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+16 +/–
	Сообщение от Аноним (25), 17-Сен-24, 15:12
	Нельзя было что-ли сделать раст нормальным языком? Тогда бы все на него перешли.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–2 +/–
	Сообщение от Проходил мимо (?), 18-Сен-24, 07:45
	Rust - это нормальный язык. В чем-то даже офигенный. Просто факт в том, что не все иксперды с OpenNET способны его осилить. Реально некоторые косяки есть не с самим языком а с отдельными вещами в стандартной библиотеке Rust, но их, при желании, так или иначе можно обойти.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (314), 18-Сен-24, 17:49
	Ясно, не язык плохой, а программисты плохие. Где-то мы это уже слышали.
	Ответить | Правка | Наверх | Cообщить модератору

	378. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Проходил мимо (?), 19-Сен-24, 07:19
	Вы таки думаете, что среди хаящих Rust икспердов с OpenNET есть программисты?
	Ответить | Правка | Наверх | Cообщить модератору

	52. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (52), 17-Сен-24, 16:01
	Давно уже есть smart pointers в C++. unique_ptr с move semantics это то что в Rust реализуется как владение (ownership) с той разницы что в C++ это не реализовано  на уровне компиляции программы, а во время выполнения. Что мешает делать подобные вещи во время компиляции? Ничего.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	80. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (39), 17-Сен-24, 16:46
	> move semantics это то что в Rust реализуется как владение (ownership) Эмм... Нет, это вообще практически не связанные вещи. В плюсах компилятор не знает и знать не может, что ты там внутри своих unique_ptr делаешь.
	Ответить | Правка | Наверх | Cообщить модератору

	283. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (283), 18-Сен-24, 12:37
	нет в C++ move-семантика изначально убогая, т.к. делалась с оглядкой на обратную совместимость искать "c++ destructive move", если что
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	57. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Karl Richter (?), 17-Сен-24, 16:03
	А в чем костыль? В компилятор не смогут реализовать статическую проверку памяти для C++?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	196. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от yet another anonymous (?), 17-Сен-24, 23:33
	При наличии indirect pointers? Флаг вам в руки и ветер в спину.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (52), 17-Сен-24, 16:06
	Другое дело что ownership (владение) давно уже реализовано в Spark (язык Ada) и было заново переизобретено в Rust
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

15. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от Аноним (15), 17-Сен-24, 15:05
1. зачем чучхе, вместо интеграции в clang и LLVM? 2. Есть же уже Cabron.
Ответить | Правка | Наверх | Cообщить модератору

	32. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (-), 17-Сен-24, 15:33
	1. Ну так свой продвигает, разве не очевидно? 2. Карбона нет. github.com/carbon-language/carbon-lang "Carbon Language is currently an experimental project." Причем они сами рекомендуют использовать раст если есть возможность. "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should"
	Ответить | Правка | Наверх | Cообщить модератору

	285. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (285), 18-Сен-24, 13:17
	Как будто сабж не экскрементальный.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 17:52
	Swift и Kotlin будут получше и перспективнее с точки зрения работы. В Swift также есть Automatic Reference Counting (ARC), что гораздо более практично для безопасного управления памятью.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	75. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Маняним (?), 17-Сен-24, 16:28
	Гугли, после того как их выкинули из С++ комитета за попытку загнуть плюсы под свои хотелки, высрали кирпичей и один из них оказался карбон. Но как оказалось звездеть о новом убийце плюсов проще чем создать востребованный язык и потому карбон так и остался кирпичом.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	96. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (95), 17-Сен-24, 17:24
	Бедный Гугл быстро нашел раст на замену плюсов (для нового кода). А гордый коммитет сейчас питыется лепить костыли. Может если бы послушали гугловцев, то идеи начали реализовывать лет 5-8 назад, а не только начинать разглагольствовать.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–2 +/–
	Сообщение от ProfessorNavigator (ok), 17-Сен-24, 16:29
	> Есть же уже Cabron. Да, есть. И даже не один. Только это - не ЯП. Посмотрите перевод слова "cabron" с испанского...
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	284. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (285), 18-Сен-24, 13:15
	Я как бы знаю, игра слов намеренная.
	Ответить | Правка | Наверх | Cообщить модератору

	287. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 18-Сен-24, 13:22
	> Я как бы знаю, игра слов намеренная. Ну тогда будем считать, что я шутку оценил))
	Ответить | Правка | Наверх | Cообщить модератору

21. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
Сообщение от Аноним (21), 17-Сен-24, 15:09
Теперь еще это в сишку, чтоли, запилить - и вообще нормуль. А то плюсы - больно уж навороченные. И это вовсе и не фича даже.
Ответить | Правка | Наверх | Cообщить модератору

	41. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (7), 17-Сен-24, 15:42
	Уже запилили: https://en.wikipedia.org/wiki/Zig_(programming_language)#Memory_handling
	Ответить | Правка | Наверх | Cообщить модератору

	48. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 15:56
	О... опять эта поделка. Когда оно мне попадалось пару лет назад на глаза, то позволяло весело и непринужденно делать всякие непотребства. var hello = try allocator.dupe(u8, "zig sucks"); allocator.free(hello); std.debug.print("{s}\n", .{hello}); и получаем use after free Не знаю исправил ли автор такое, но судя по доке где Out of Bounds Float to Integer Cast TODO оно еще очень сырое.
	Ответить | Правка | Наверх | Cообщить модератору

	317. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 17:55
	Пару лет назад это вечность для нового языка. Сейчас многие переходят на Zig, разочаровавшись в Rust, так что его развитие заметно ускорилось. У него больше перспектив.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (175), 17-Сен-24, 22:29
	>Уже запилили >First appeared 8 February 2016; 8 years ago >Preview release 0.13.0 Сейчас языка нет, есть только идея языка, без обратной совместимости. И с учётом времени прошедшего после начала разработки, в ближайшем времени ничего не будет. Если иметь чёткое представление, что должно получится, то можно за условные пару месяцев реализовать первую версию, и объявить о стабилизации апи, после чего можно годами неспешно расширять библиотеки. Если же чёткого представления нет, то будут пробы разных подходов, с отказам от них, что выльеться в постоянное переписывание разных частей.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	271. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Самый умный аноним (?), 18-Сен-24, 10:27
	> можно за условные пару месяцев реализовать первую версию Пара месяцев это для новичков. Ты за 21 день бы сделал новый язык
	Ответить | Правка | Наверх | Cообщить модератору

	318. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 17:58
	>Если иметь чёткое представление, что должно получится, то можно за условные пару месяцев реализовать первую версию, и объявить о стабилизации апи, после чего можно годами неспешно расширять библиотеки. Что же тогда разработчики Раста не использовали этот разумный подход, а вместо него: >Если же чёткого представления нет, то будут пробы разных подходов, с отказам от них, что выльеться в постоянное переписывание разных частей.
	Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

	343. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 19:14
	>Что же тогда разработчики Раста не использовали этот разумный подход, а вместо него: Раст уже давным давно зарелизил 1.0, и имеет обратную совместимость https://doc.rust-lang.org/edition-guide/editions/
	Ответить | Правка | Наверх | Cообщить модератору

	238. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от bOOster (ok), 18-Сен-24, 08:23
	Не осиливаешь все навороты - пользуйся только тем что осиливаешь. Никаких проблем с этим нет. Шаблоны мощная штука - но многие их реализации практически нечитаемы и сложны в понимании и отладке.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

24. Скрыто модератором	–1 +/–
Сообщение от Fjyj (-), 17-Сен-24, 15:11
"Сначала они тебя не замечают, потом смеются над тобой, затем борются с тобой. А потом т̶ы̶ ̶п̶о̶б̶е̶ж̶д̶а̶е̶ш̶ь̶ они начинают копировать твои идеи" Вот оно признание от плюсовиков: что их язык из прошлого века не может обеспечить нынешние требования к программам, что есть идеи которые позволяют сделать лучше, что надо что-то делать... Но думаю если оно пойдет в стандарт, то это будет в году так 2030 или даже позже. Пока коммитет позаседает, пока все обсудят... Ну и слом совместимости (особенно в мозгах дидов) тоже неизбежен.
Ответить | Правка | Наверх | Cообщить модератору

26. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+4 +/–
Сообщение от Аноним (15), 17-Сен-24, 15:16
>#feature on safety В C и C++ для этого используются #pragma
Ответить | Правка | Наверх | Cообщить модератору

	237. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от bOOster (ok), 18-Сен-24, 08:18
	Точно. на текущий момент есть always acceptable #pragma region .... #pragma endregion .... Реализовать логику #pragma region safe/unsafe Особой проблемы нет.
	Ответить | Правка | Наверх | Cообщить модератору

27. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+5 +/–
Сообщение от Аноним (39), 17-Сен-24, 15:16
> переводить проекты на безопасные методы, сохраняя при этом совместимость с уже существующим "небезопасным" кодом. Странная идея. Нужен Раст - берите Раст, в чем проблема-то? Если эту спеку и примут, то сперва бюрократы из комитета C++ будут мусолить ее лет шесть, а потом еще лет шесть-десять придется ждать ее сколь-нибудь сносной поддержки в компиляторах. Обалденный план  с учетом того, в Расте все эти упомянутые фичи работают прямо здесь и сейчас. Ну и самое главное: кто-то всерьез считает, что все так и ломануться переводить свои десятилетиями пишущиеся легаси-копролиты в миллионы строк C++ на эти новые костыли?
Ответить | Правка | Наверх | Cообщить модератору

	35. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (35), 17-Сен-24, 15:35
	Тяжело им в Rust идти. Вакансий нет и специалистов нет. Как они пойдут сами что ли проичтабт книжку?
	Ответить | Правка | Наверх | Cообщить модератору

	112. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (112), 17-Сен-24, 18:08
	Просто выкинут раст и всё.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (-), 17-Сен-24, 15:45
	> Странная идея. Нужен Раст - берите Раст, в чем проблема-то? Тогда г-н Vinnie Falco не сможет влиять на развитие языка и на программеров, которые им будут пользоваться. Когда у тебя есть власть, то всегда хочется еще. > Ну и самое главное: кто-то всерьез считает, что все так и ломануться переводить свои десятилетиями пишущиеся легаси-копролиты в миллионы строк C++ на эти новые костыли? Ну.. во-первых были бы деньги))) Во-вторых - даже если завернуть в эти костыли какие-то особо кривые куски кода, типа парсинг пользоватльского ввода - то уже стало бы гораздо лучше. Но да, возникнет вопрос "а чего не создать раст обертку?" Как поступает например гугл.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	319. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:01
	Проблема в том, что это другой, несовместимый с C++ язык, который хорошо знают только его создатели. И для него в первую очередь справедливо утверждение >кто-то всерьез считает, что все так и ломануться переводить свои десятилетиями пишущиеся легаси-копролиты в миллионы строк C++ на эти новые костыли? тогда как на новый C++ переписать его будет вполне реально.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

28. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
Сообщение от Аноним (15), 17-Сен-24, 15:17
>mut >std2 >safe Можно хоронить. Плюсовые компиляторы сами умеют определять. Вместо того, чтобы всё вручную аннотировать, нужно развивать встроенный статический анализ.
Ответить | Правка | Наверх | Cообщить модератору

	30. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (30), 17-Сен-24, 15:27
	> сами Неверно. Проблема pointer provenance до сих пор не решена в силу ее сложности. См. статьи Ralf Jung.
	Ответить | Правка | Наверх | Cообщить модератору

29. Скрыто модератором	–1 +/–
Сообщение от Аноним (29), 17-Сен-24, 15:19
Вот с таким же, незнаю как это назвать, "стремлением", "рвением", "жаждой", "одержимостью", "кровьизносостью", "дуростью", "дебилизмом", "укуренностью", "смузизахлеблённостью" ли могли бы продвигать механизмы безопасТных компьютерный (аппаратных) архитектур. Ведь грош цена вашему "механизму безопасТной работы памяти" при заведомо небезопасТной аппаратной  архитектуре этой "памяти", все яйца в одной корзине, и как их не пытайся складывать, разобьются все.
Ответить | Правка | Наверх | Cообщить модератору

36. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+4 +/–
Сообщение от eugene_martein (ok), 17-Сен-24, 15:37
Я принёс вам современное безопасное программирование на C++: target_compile_options(${target} PRIVATE                 -Wall                 -Werror                 -Wextra                 -Wpedantic                 -pedantic-errors                 -Wunused                 -Wctor-dtor-privacy                 -Wnon-virtual-dtor                 -Wnrvo                 -Wimplicit-fallthrough                 -Wshift-negative-value                 -Wswitch-default                 -Wswitch-enum                 -Wuseless-cast                 -Wuninitialized                 -Wstrict-overflow=5                 -Wstringop-overflow=4                 -Warray-bounds=2                 -Wduplicated-cond                 -Wfloat-equal                 -Wshadow                 -Wunsafe-loop-optimizations                 -Wcast-qual                 -Wconversion                 -Wparentheses                 -Wenum-conversion                 -Wflex-array-member-not-at-end                 -Wlogical-op                 -Wmissing-declarations                 -Wpacked                 -Wredundant-decls                 -Winline             )
Ответить | Правка | Наверх | Cообщить модератору

	37. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (37), 17-Сен-24, 15:38
	Видимо ты не знаешь о существовании -Weverything
	Ответить | Правка | Наверх | Cообщить модератору

	44. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 15:50
	Явное указание все опций не сломает сборку на новом компиляторе, если в эврифинг что-то добавят.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–2 +/–
	Сообщение от Аноним (39), 17-Сен-24, 15:56
	> Явное указание все опций не сломает сборку на новом компиляторе, Каким образом предупреждения могут сломать сборку?
	Ответить | Правка | Наверх | Cообщить модератору

	53. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+5 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 16:01
	>> Явное указание все опций не сломает сборку на новом компиляторе, > Каким образом предупреждения могут сломать сборку? -Werror
	Ответить | Правка | Наверх | Cообщить модератору

	62. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (39), 17-Сен-24, 16:05
	-Werror не входит в -Weverything.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от 12yoexpert (ok), 17-Сен-24, 17:58
	учи матчасть. ты понятия не имеешь, о чём говорят в этой ветке. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
	Ответить | Правка | Наверх | Cообщить модератору

	134. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (99), 17-Сен-24, 19:02
	> учи матчасть. ты понятия не имеешь, о чём говорят в этой ветке. ... и кидает ссылку да доку GCC. Чел, -Weverything - это опция clang. Хотел поумничать, но как всегда сел в лужу.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+4 +/–
	Сообщение от 12yoexpert (ok), 17-Сен-24, 19:22
	тебе про Фому, ты про Ерёму. иди читай, что такое -Werror
	Ответить | Правка | Наверх | Cообщить модератору

	59. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (7), 17-Сен-24, 16:04
	-Werror
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	65. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (39), 17-Сен-24, 16:07
	-Werror - это не предупреждение и в -Weverything не входит 🤦
	Ответить | Правка | Наверх | Cообщить модератору

	69. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 16:15
	> -Werror - это не предупреждение и в -Weverything не входит 🤦 И дальше что? Оно указано отдельно в начальном комментарии.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (39), 17-Сен-24, 16:26
	> И дальше что? То, что ты умничаешь в ветке, где ответили на: > Явное указание все опций не сломает сборку на новом компиляторе, если в эврифинг что-то добавят.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 17:46
	Опять кексперт пытается поднять своё эго в комментариях. Изначально обсуждались конкретные опции и там был werror, перечитай ветку.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (99), 17-Сен-24, 19:15
	> Изначально обсуждались конкретные опции и там был werror, перечитай ветку. Нет, обсуждалось конкретно твое заявление "Явное указание всех опций не сломает сборку на новом компиляторе, если в *эврифинг* что-то добавят". Когда тебе написали, что новые проверки -Weverything сломать ничего не могут (ибо они только предупреждения), ты в ответ с умным видом упомянул -Werror. Который вообще сам по себе не ворнинг и потому в -Weverything никогда не будет добавлен. Ну а потом твои аргументы вообще съехали в "и что дальше?" и "кексперт". Опять экперт уровня "слышал звон" пытался поумничать, но сел в лужу...
	Ответить | Правка | Наверх | Cообщить модератору

	162. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:24
	>> Изначально обсуждались конкретные опции и там был werror, перечитай ветку. > Нет, обсуждалось конкретно твое заявление "Явное указание всех опций не сломает сборку > на новом компиляторе, если в *эврифинг* что-то добавят". Выше читай https://www.opennet.ru/openforum/vsluhforumID3/134833.html#37 и https://www.opennet.ru/openforum/vsluhforumID3/134833.html#36 где и указаны опции и если бы ты внимательно почитал, то увидел бы там -werror.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Соль земли (?), 17-Сен-24, 18:54
	Лучше, если сломает. Явное лучше неявного.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	61. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (50), 17-Сен-24, 16:05
	Ещё бы к этому добру аналог: cargo fix
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

38. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от Аноним (38), 17-Сен-24, 15:39
Позитив. Ибо нефиг выпендриваться. Тоже могём.
Ответить | Правка | Наверх | Cообщить модератору

45. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
Сообщение от keydon (ok), 17-Сен-24, 15:51
Раст здорового человека.
Ответить | Правка | Наверх | Cообщить модератору

47. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
Сообщение от Karl Richter (?), 17-Сен-24, 15:55
Вот, теперь C++ начало этим заниматься, потому что есть потребность в это. В первую очередь, потребность США по кибербезопасности.
Ответить | Правка | Наверх | Cообщить модератору

	56. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 16:03
	> Вот, теперь C++ начало этим заниматься, потому что есть потребность в это. > В первую очередь, потребность США по кибербезопасности. Им потребно наличие бэкдоров. На расте можно встроить прямо в компилятор, затимв разум неокрепшим умам верой в безопасность.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 16:07
	> Им потребно наличие бэкдоров. Всем потребно. Но кроме бекдоров есть еще и дыры. И они не хотят, чтобы их ломали через эти дыры всякие узкоглазые и чучхе. > На расте можно встроить прямо в компилятор Можно. И в сишку можно. Но в сишке проще на null проверочку забыть.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 16:14
	>> Им потребно наличие бэкдоров. > Всем потребно. Но кроме бекдоров есть еще и дыры. > И они не хотят, чтобы их ломали через эти дыры всякие узкоглазые > и чучхе. В эту игру в одного не играют. >> На расте можно встроить прямо в компилятор > И в сишку можно. Компилятор для си можно забутстрапить, притом там все начинается с простого компилятора, написанного на scheme, которым уже потом собирается tcc. Кто собирает раст? Где исследование исходников на бэкдоры? Одна реализация по факту, все качают бинари. Куда проще встроить?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Karl Richter (?), 17-Сен-24, 16:21
	В эту игру играют в OpenSorce ПО.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (201), 18-Сен-24, 00:56
	Ты не понял.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 16:46
	> Компилятор для си Какой именно)? У нас их просто куча! Даже пованивает, тк минимум половина уже померла и разложилась. > притом там все начинается с простого компилятора, написанного на scheme, которым уже потом собирается tcc. ... а потом им делают use-after-free Потому что оно ущербное dy design) Раст кстати тоже можно бустстрапить github.com/rust-lang/rust/tree/master/src/bootstrap > Кто собирает раст? Очевидно что такой же несчастный, как те что собирают gcc gcc.gnu.org/mirrors.html Чего можно напхать в tar.gz мы уже видели на примере библиотеки XZ > Где исследование исходников на бэкдоры? Не знаю, можешь поискать. > Одна реализация по факту, все качают бинари. И много людей собирают из исходников GCC и CLang? Точно так же качают из исходников. И ядро тоже, и пакеты. Те кто не в секте гентушников все так делают. > Куда проще встроить? Зачем что-то встраивать в компилятор, если проще сделать out-of-bounds прямо в коде? Или просто внести бекдор в ядро, которое мало кто сам соберет.. А стоп, так уже сделали - Bvp47 жил в ядре 10 лет.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	163. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:27
	> Раст кстати тоже можно бустстрапить > github.com/rust-lang/rust/tree/master/src/bootstrap > Bootstrap build system goes through a few phases to actually build the compiler. What actually happens when you invoke bootstrap is: > 1. The entry point script (x for unix like systems, x.ps1 for windows systems, x.py cross-platform) is run. This script is responsible for downloading the stage0 compiler/Cargo binaries То есть на первом шаге бутстрапинга предлагается скачать бинари компилятора и cargo? Это бред.
	Ответить | Правка | Наверх | Cообщить модератору

	364. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 23:55
	>То есть на первом шаге бутстрапинга предлагается скачать бинари компилятора и cargo? Это бред. Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. А вы что предлагаете, скачивать llvm ir код? Для тех, кто не доверяет текущему компилятору есть возможность собирать его версию за версией, начиная с той, что написана на ocaml.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:28
	> И много людей собирают из исходников GCC и CLang? Clang хз, gcc - да.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	165. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:29
	> Зачем что-то встраивать в компилятор, если проще сделать out-of-bounds прямо в коде? За свой код ответственнен ты. За компилятор нет, как и за уровни ниже. Разницу понимаешь?
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	200. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (201), 18-Сен-24, 00:55
	> У нас их просто куча! А знаешь почему? Потому что есть стандарт. > Даже пованивает Пока тут ты пованиваешь только.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	216. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Прохожий (??), 18-Сен-24, 02:44
	>Потому что есть стандарт. Конечно, причина не в этом. Обусловлено это всё относительной простотой языка и разнообразием архитектур. Отсутствие стандарта для того же Rust не помешало разработчикам gcc начать создание для него компилятора.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (112), 18-Сен-24, 09:41
	Начать, начать, Карл!
	Ответить | Правка | Наверх | Cообщить модератору

	321. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:07
	Закончить помешало. Как обычно.
	Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

	71. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Karl Richter (?), 17-Сен-24, 16:18
	Бэкдоров полно, что в ПО, что в процессорах. У США явно будет/есть возможность получить к ним доступ. А обезопасить свою инфраструктуру не только от бэкдоров, но и багов - это задача. Уязвимости, связанные с памятью - самые распространенные, поэтому Rust привлекателен.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	82. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (29), 17-Сен-24, 16:49
	> Уязвимости, связанные с памятью там выше мой комент как раз про это - скрыли, ну пусть с такой же "пеной у рта" придумают "безопасТную модель памяти", а не 1000500-ый "безопасТный механизм" работы с "небезопасТной моделью памяти".
	Ответить | Правка | Наверх | Cообщить модератору

	217. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Прохожий (??), 18-Сен-24, 02:49
	Твой комментарий выше - это мешанина тёплого с мягким, или мух с котлетами. Небезопасные языки добавляют проблем к потенциально нестабильной работе аппаратной памяти. Люди пытаются с этим бороться с помощью безопасных языков. Вроде, простая мысль. А поди ж ты, приходится разжевывать.
	Ответить | Правка | Наверх | Cообщить модератору

	289. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (29), 18-Сен-24, 14:23
	> Твой комментарий выше - это мешанина тёплого с мягким, или мух с котлетами. а кто-то отменил существование котлет из мух? азиаты с вами бы поспорили бы, у них там бигмак из тараканов есть, это как про "мешанину Канта", Кантом надо быть, чтобы понять, короче, проехали. > Небезопасные языки добавляют проблем к потенциально нестабильной работе аппаратной памяти. Нету такого определения "небезопасТные" или "безопасТные" языки. Определение "потенциальная нестабильность" не приемлема там где необходима "надежность" аппаратная. Вы хотите сказать, что допустимо, что-либо "аппаратно-нестабильное" использовать там где необходима "надежность"? > Люди пытаются с этим бороться с помощью безопасных языков. Нету определения "безопасТных" языков. То есть люди должны были строить мельницы не похожие на мельницы, чтобы доны Кихоты с ними не сражались, за место того, чтобы лечить самих донов? > Вроде, простая мысль. А поди ж ты, приходится разжевывать. Ну да, простая, вот и я разжевал: «Класть все яйца в одну корзину» — народная поговорка, которая говорит о том, что как раз не стоит этого делать. Потому как положил все яйца в одну корзину, уронил ее нечаянно — и остался без яиц.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 18:00
	> что в процессорах Поэтому важно в этом направлении тоже развиваться. > поэтому Rust привлекателен Пока что это решение вендорлок, со стремным вектором развития, одной реализацией, странным сообществом.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	121. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (-), 17-Сен-24, 18:31
	> Пока что это решение вендорлок, Что правда? Там те самые компании в foundation'е сидят, что и в ядре. И почти те же самые корпорации, что в коммитете С++. > со стремным вектором развития, стремное - это твое мнение, на которое, как ты догадываешься, всем плеевать но зато развитие есть, а не деградация > одной реализацией, Неправда, есть как минимум 2 компилятора + еще несколько надстроект ferrocene. Другое дело, что тут нет такого "мы не знаем как сложить 2 числа, пусть разработчики компилятора как-то сделают" > странным сообществом. Тоже оценочное мнение. На код и его работоспособность не влияет. Я понимаю, что многие по понятиям начинают заглядывать разработчикам в труселя...
	Ответить | Правка | Наверх | Cообщить модератору

	195. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от yet another anonymous (?), 17-Сен-24, 23:22
	cargo, доставка on-the-fly, и т.д. Конечно, rust привлекателен. Для доставки чего надо куда надо.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	79. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (29), 17-Сен-24, 16:44
	> В первую очередь, потребность США по кибербезопасности. они 4 летний опыт работы отменили буквально на днях, делайте вывод.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

54. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
Сообщение от Аноним (60), 17-Сен-24, 16:01
Я как программист полностью одобряю: теперь мне ту же работу нужно будет делать в 5 раз дольше, а мне кредит за дом платить и вообще деньги откладывать. а на плюсах быстро всё сделал и не остаётся уже, что делать
Ответить | Правка | Наверх | Cообщить модератору

	70. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 16:18
	Глупости ты говоришь. Да возможно переписать займет не год, а пять.. (в чем я очень сомневаюсь тк гугл переучивает 2/3 гошников и фортовиков на раст, за 2 месяца!) А если писать на С - то можно годами ковырять древние баги, которым по 20-30 лет, и создавать новые, для будущих поколений. Как в том анекдоте про адвокатов "Что же ты сынок наделал! Это дело нас уже четверь века кормило!!"
	Ответить | Правка | Наверх | Cообщить модератору

	139. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (99), 17-Сен-24, 19:21
	> а на плюсах быстро всё сделал и не остаётся уже, что делать В смысле "не остается"? Если в плюсах "быстро все сделал", то у тебя еще на полгода вперед будет работы над списоком багов из-за висячих ссылок, протухших итераторов, выходов за пределы буфера, UB и прочих C++ чудес. Ты наоборот должен быть против!
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	153. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Bottle (?), 17-Сен-24, 19:49
	>выходов за пределы буфера Используй умные указатели. >UB В C++ используются нормальные строки, это уже улучшает ситуацию значительно.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 04:13
	>Используй умные указатели. В лучшем случае получится только в своём коде, но не в библиотечном.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (250), 18-Сен-24, 09:31
	А, ну да, Rust же не используют библиотеки, написанные на C.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (241), 18-Сен-24, 09:59
	Какое мастерское приплетание Расте в ветке обсуждения C++...
	Ответить | Правка | Наверх | Cообщить модератору

	323. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (314), 18-Сен-24, 18:15
	Какой детский уход от темы.
	Ответить | Правка | Наверх | Cообщить модератору

	354. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 20:59
	Если уж брать раст, то там можно взять банальный grep и проверить. А вот в плюсах - нельзя. И говоря про выход за границы, то непонятно, это обычный массив, или оператор индексации. Это уже как минимум языковой сервер нужен
	Ответить | Правка | Наверх | Cообщить модератору

	295. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (295), 18-Сен-24, 16:10
	> теперь мне ту же работу нужно будет делать в 5 раз дольше ... а на плюсах быстро всё сделал и не остаётся уже, что делать Тебе? Может быть. У середнячков-неосиляторов нового всегда так. А у чуть более хороших разработчиков, у которых мозги еще не заржавели, вот так: Ларс Бергстром (технический директор Google): "Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++". (это он в марте на какой-то конференции заявлял) "...Some additional context on these two specific claims: Google found that porting Go to Rust "it takes about the same sized team about the same time to build it, so that's no loss of productivity" and "we do see some benefits from it, we see reduced memory usage [...] and we also see a decreased defect rate over time" On re-writing C++ into Rust: "in every case, we've seen a decrease by more than 2x in the amount of effort required to both build the services written in Rust, as well as maintain and update those services. [...] C++ is very expensive for us to maintain." Так что так. "C++ очень дорог для нас в обслуживании". Причем "дорог" здесь, как ты понимаешь, не положительная оценка. С++ как раз, для таких, как ты, которые "...мне ту же работу [c C++] нужно будет делать в 5 раз [в два раза] дольше, а мне кредит за дом платить и вообще деньги откладывать...". А главное! главное! - потом годами сопровождать, ошибки искать и фиксить. Главное неспеша, по одной, чтобы до пенсии хватило. Ну прям как в том анекдоте про юристов отца и сына.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	324. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:18
	Да ты это уже раз 50 в комменты вставлял. И одно это говорит как мало положительных отзывов о внедрении Rust в реальные проекты.
	Ответить | Правка | Наверх | Cообщить модератору

77. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
Сообщение от leap42 (ok), 17-Сен-24, 16:33
Надо добавить все фичи всех языков... и не останавливаться на этом 😆😆😆
Ответить | Правка | Наверх | Cообщить модератору

	255. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (250), 18-Сен-24, 09:30
	А не остановившись, что же добавлять дальше?
	Ответить | Правка | Наверх | Cообщить модератору

78. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–6 +/–
Сообщение от НяшМяш (ok), 17-Сен-24, 16:34
Этап "принятие". Видимо ощутили, как от плюсовиков денежки утекаю, вот и начали суетиться и воровать хорошие идеи. Безопаснее кресты конечно же не станут, а вот повыступать на конференциях и пособирать донаты на этом ужасе - благое дело.
Ответить | Правка | Наверх | Cообщить модератору

	92. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от Аноним (123), 17-Сен-24, 17:14
	Таким как ты не угодишь. Не тащат в С++ фичи Раста - плохо. Тащат - тоже плохо.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 17-Сен-24, 17:29
	> Не тащат в С++ фичи Раста - плохо. Кто сказал что плохо? Те самые, которые кричали "ненужОн нам ваш раст с его боровом, нам и с++ хватит!" ? Или это другие?)) > Тащат - тоже плохо. Наоборот хорошо! До них наконец-то стало доходить!
	Ответить | Правка | Наверх | Cообщить модератору

	325. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:19
	Ну вот теперь C++ действительно хватит, непонятно чем ты недоволен ))
	Ответить | Правка | Наверх | Cообщить модератору

	120. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (120), 17-Сен-24, 18:24
	Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	125. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (-), 17-Сен-24, 18:39
	> Принятия что все будет в плюсах и ни в каком расте нет необходимости? А когда будет? В 26 стандарт уже не попадает, в 29й тоже сомнительно. Т.е возможно, если они договорятся в 32-35 году на плюсовиком снизойдет благодать. > Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет. Странно, раньше талдычили что "раст не нужон! боров ваш тоже не нужон!! смартпойнтеров всем хватит!". А тут целый президент C++ Alliance говорит "там классные идеи". Вот это переобувание в прыжке))
	Ответить | Правка | Наверх | Cообщить модератору

	127. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (112), 17-Сен-24, 18:46
	Так в нынешнем стандарте и ненужен. А в будущем может ещё телепатию в стандарт примут кто знает.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (99), 17-Сен-24, 20:00
	> А тут целый президент C++ Alliance говорит "там классные идеи". > Вот это переобувание в прыжке)) Так это засланный казачок от проклятых корпораций коварно пускает метастазы раковой опухоли в чистый, свободный, независимый сад C++ 😂
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	144. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (99), 17-Сен-24, 19:27
	> Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет. Только вот в Расте это все уже есть здесь и сейчас. А в плюсах нет и не будет ближайшие лет 10 точно. Талдычте дальше...
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	146. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (112), 17-Сен-24, 19:37
	Трехтысячный раз лично тебе повторяю. Раст это отсутствие совместимости между версиями и полное отсутствие бекпортировпния фиксов в старые версии. Ужасный синтаксис переполненный спецсимволы и ужасное комьюнити. Поэтому раст не может взлететь как концепция. Борова почекать можно в с++ прям сейчас. Умные указатели нет ничего проще. Добавить новую спецификацию в будущем почему бы и нет.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (99), 17-Сен-24, 19:45
	Как скажешь.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (39), 17-Сен-24, 19:48
	> Борова почекать можно в с++ прям сейчас. Умные указатели нет ничего проще. Oh my sweet summer child... Я смотрю, чем меньше эксперт шарит в C++ и Rust, тем сильнее у него "нет ничего проще" и "Rust не нужен".
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	157. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (112), 17-Сен-24, 20:05
	Чекер борова просто при существовании алиаса для ссылки запрещает мутации. Чем ужасно всех бесит даже адептов раста. И пишется кем угодно левой ногой настолько он приметивен.
	Ответить | Правка | Наверх | Cообщить модератору

	269. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (241), 18-Сен-24, 10:15
	> Чекер борова просто при существовании алиаса для ссылки запрещает мутации. Так может в этом есть какой-то смысл? Или для всего непонятного у тебя есть одно универсальное объяснение, что авторы - дураки? > И пишется кем угодно левой ногой настолько он приметивен. Молодец: ты еще раз подтвердил утверждение выше "чем меньше эксперт шарит в C++ и Rust, тем сильнее у него "нет ничего проще".
	Ответить | Правка | Наверх | Cообщить модератору

	174. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 17-Сен-24, 21:11
	>Раст это отсутствие совместимости между версиями https://doc.rust-lang.org/edition-guide/introduction.html >Ужасный синтаксис переполненный спецсимволы Взяли худшее от семейства си. Кресты так же уродливы, со своими cout << "123"; T<A> a; [&, i]{}; [=, *this]{ };
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	231. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от bOOster (ok), 18-Сен-24, 07:37
	В С++ у тебя есть выбор писать коряво спецсимволами либо в нормальный синтаксис. В расте этой возможности много где нет.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Проходил мимо (?), 18-Сен-24, 08:26
	Не будет ли любезен многоуважаемый джинн привести небольшой пример кода на Rust с "корявыми спецсимволами" и "ненормальным синтаксисом"? Как человек, который иногда пишет всякие полезные вещи на данном языке, мне стало очень интересно посмотреть на подобное, потому что я, в своей скромной практике, с подобным почти не встречался. Лично мне вот не нравится синтаксис, когда надо руками указывать время жизни - на мой взгляд решение с апострофом явно неудачное и невнятное. Все остальное вполне нормальное и достаточно понятное. Пример кода для того, чтобы те, кто не в курсе про Rust вообще и про время жизни в частности, поняли о чем речь: //------------------------------------------------------------------- //  Структура для описания поля. Время жизни 'a необходимо, чтобы ссылка //  на внешний буфер buf внезапно не оказалась висячей pub struct  Field<'a> {     //  Ссылка на внешний буфер для разбора     buf:    &'a[u8],     //  Позиция начала текущего поля     f_pos:  usize,     //  Флаг окончания строки     endl_flag:  bool, } //------------------------------------------------------------------- //  Методы для структуры Field impl<'a>    Field<'a> {     //-----------------------------------------------------------     //  Сохраним ссылку на внешний буфер     pub fn  from_buf( slice: &'a[u8] ) -> Field<'a>     {         // Конструктор возвращает экземпляр структуры Field, в которой сохранена ссылка         // на внешний буфер, из которого потом будут выделяться поля         Field         {             buf : slice,             f_pos:  0,             endl_flag:  false,         }     }     //----------------------------------------------------------- } //-------------------------------------------------------------------
	Ответить | Правка | Наверх | Cообщить модератору

	270. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (241), 18-Сен-24, 10:16
	> В С++ > нормальный синтаксис Ты же шутишь, да?
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	308. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (310), 18-Сен-24, 17:24
	Что из этого необычный синтаксис плюсов?
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	232. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от bOOster (ok), 18-Сен-24, 07:40
	А писать несколько операторов в одну строчку - это неизлечимая болезнь в мозгу недопрограммиста.
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	235. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Проходил мимо (?), 18-Сен-24, 08:03
	Не надо пороть чушь - ей больно. Написанное вами показывает, что в предмете вы не разбираетесь от слова совсем и язык Rust просто не осилили.
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	297. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (295), 18-Сен-24, 16:25
	> Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычим О какое виртуозное переобувание в воздухе. Лицемеры. Вы который год уже талдычите, что Настоящему Погроммисту все эти ваши боровы чекеры и битиЕ компилятором линейкой по рукам не нужно, ибо Он, Богоподобный Погроммист, сам всё знает и умеет, и, главное, НЕ ОШИБАЕТСЯ (а кто ошибается, те не настоящие и гнать их в дворники). А тут такое.
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	326. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:31
	Вы хотели чекер борова - вам дают чекер борова в C++. Но внезапно это оказывается - "воровать хорошие идеи". И он еще что-то говорит про лицемерие.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:32
	> воровать хорошие идеи Какое слово нехорошее подобрал, явно специально. Раст, конечно, все изобрел с нуля. Многие идеи перекачевывают из проекта в проект. Что в этом плохого?
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	203. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (201), 18-Сен-24, 01:00
	> Видимо ощутили, как от плюсовиков денежки утекают, вот и начали суетиться и воровать хорошие идеи. Не пишешь на плюсах, вот и бесишься!
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

122. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
Сообщение от Аноним (122), 17-Сен-24, 18:35
Оригинал всегда лучше копии!
Ответить | Правка | Наверх | Cообщить модератору

	128. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (112), 17-Сен-24, 18:47
	Да Пёрл лучше всех.
	Ответить | Правка | Наверх | Cообщить модератору

	258. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (250), 18-Сен-24, 09:36
	Нишевый язык. Можно сказать, DSL.
	Ответить | Правка | Наверх | Cообщить модератору

	327. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:33
	У нас вестник из будущего, ловите!
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

169. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
Сообщение от Аноним (175), 17-Сен-24, 20:58
Спали, спали, зачем проснулись? Итак, какие минусы у данного решения? Ошибки, в частности ошибка на миллиард долларов(наличие null) из плюсов никуда не денется. Существующие проекты, если и будут переписываться, то всё это будет крайне медленно. Понять, переписан уже какой-то проект или нет будет крайне затруднительно, особенно для тех, кто не знаком именно с плюсами. Часть проектов будут сочетать в себе безопасные и небезопасные части, при этом любой коммит будет менять их в произвольные стороны. Это не раст, в котором нужно оборачивать код в unsafe. Время компиляции: в плюсах есть десятки разных способов затормозить компиляцию, начиная с возможности инклюдить произовльные файлы в произвольные места, в том числе с возможностью циклических зависимостей(аналогичная проблема в си), продолжая всякими шаблонами и прочим. Судя по всему, коммитет это не волнует. Код хромиума уже может собираться больше суток на среднем ноутбуке, упираясь как в количество ядер, так и в количество оперативки, без возможности как-то это ускорить. Стандарт плюсов уже огромен, со всем этим он станет ещё больше. И самое главное: появление этих возможностей никак не заставит разработчиков им следовать. Некоторые пишут на си с классами, теряя часть гарантий плюсов, типа умных указателей. Так что закапывайте уже плюсы. Хотите - создавайте новый язык, хотите, развивайте любой существующий. Посмотрите на фичи других языков, типа зависимых типов в ATS.
Ответить | Правка | Наверх | Cообщить модератору

	205. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:04
	> Код хромиума уже может собираться больше суток на среднем ноутбуке, упираясь как в количество ядер, так и в количество оперативки, без возможности как-то это ускорить. На расте он быстрее будет собираться что-ли? > типа зависимых типов И зачем они если тебе не нужны доказательства?
	Ответить | Правка | Наверх | Cообщить модератору

	220. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 04:16
	>На расте он быстрее будет собираться что-ли? А при чём тут раст? Я писал про то, какой монстр плюсы >если тебе не нужны доказательства С чезо вдруг тагие утверждения?
	Ответить | Правка | Наверх | Cообщить модератору

	224. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 04:29
	>С чего вдруг такие утерждения?
	Ответить | Правка | Наверх | Cообщить модератору

	292. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 15:07
	Потому что одна из основных задач для завтипов — это различные пруверы типа Идриса и кока. Если нет, то приведи пример зачем нужны завтипы для бытового программирования. Возможность взять голову пустого списка и получить ошибку не принимается.
	Ответить | Правка | Наверх | Cообщить модератору

	305. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (310), 18-Сен-24, 17:16
	>Возможность взять голову пустого списка и получить ошибку не принимается. Почему это? Вы предпочитаете попортить память/упасть? Типизация поможет в том чиле и против утечек памяти и против двойного освобождения.
	Ответить | Правка | Наверх | Cообщить модератору

	309. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 17:25
	>>Возможность взять голову пустого списка и получить ошибку не принимается. > Почему это? Вы предпочитаете попортить память/упасть? На мой взгляд это не токое важное место, чтобы так сильно усложнять систему типов. > Типизация поможет в том чиле и против утечек памяти и против двойного > освобождения. Завтипы? Можно подробнее в этом месте? Вроде же idris, coq, lean все с gc.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 19:21
	>На мой взгляд это не токое важное место, чтобы так сильно усложнять систему типов. Ими пользуются по необходимости >Завтипы? Можно подробнее в этом месте? Посмотри на ATS - язык с линейными и зависимыми типами, по умолчанию без GC, правда он скорее экспериментальный, чем практический.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:05
	> Стандарт плюсов уже огромен, со всем этим он станет ещё больше. А зачем тебя это так волнует? Вон в расте стандарта никакого нет, каждый релиз новую порцию апи публичат (и не малую).
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	226. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 04:43
	>А зачем тебя это так волнует? Вопрос возможности чтения кода посторонними людьми и понимания самим автором. А то с этим частенько бывают проблемы, когда автор сам не понимает, как должен работать его код >новую порцию апи публичат Есть огромная разница между добавлением новой семантики и новым апи. При добавлении апи, язык остаётся тем же, порой даже это можн о было бы реализовать и в старой версии, ну а с новым апи нужно в корне менять подход
	Ответить | Правка | Наверх | Cообщить модератору

	293. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 15:10
	> Вопрос возможности чтения кода посторонними людьми и понимания самим автором. А то с этим частенько бывают проблемы, когда автор сам не понимает, как должен работать его код Ты сейчас на серьезных щах утверждаешь, что все кто пишут на расте все понимают? И знают ллвм? Чтобы писать на с++ не надо досконально знать стандарт, да и кроме комитетчиков его реально мало кто знает.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (310), 18-Сен-24, 17:10
	>Чтобы писать на с++ не надо досконально знать стандарт, Я не пишу ни на c ни на c++. Однако, читая код на этих языках, регулярно вижу отсутствие понимания происходящего типа такого https://github.com/ProfessorNavigator/mylibrary/blob/b249bf8... https://habr.com/ru/articles/522208/ И я крайне сомневаюсь, что те, кто не осилили парсер не побьют память, ведь их общийуровень понимания крайне низок
	Ответить | Правка | Наверх | Cообщить модератору

	311. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 17:30
	>>Чтобы писать на с++ не надо досконально знать стандарт, > Я не пишу ни на c ни на c++. Однако, читая код > на этих языках, регулярно вижу отсутствие понимания происходящего типа такого https://github.com/ProfessorNavigator/mylibrary/blob/b249bf8... > https://habr.com/ru/articles/522208/ Можно обернуть данный код в с++ в класс, в котором надо проверять ошибку типа absl::Status, outcome::result, Boost::Outcome или std::expected из с++23. Просто это разный подход к обработке ошибок. > И я крайне сомневаюсь, что те, кто не осилили парсер не побьют > память, ведь их общийуровень понимания крайне низок Есть готовые библиотеки для разбора. Если человек не читает документацию, то проблема сильно ниже.
	Ответить | Правка | Наверх | Cообщить модератору

	345. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 19:23
	>Можно обернуть данный код в с++ в класс Для этого, нужно как минимум подозревать о проблеме. В плюсах компилятор никак не подскажет, что здесь что-то не то.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 18-Сен-24, 22:24
	> И я крайне сомневаюсь, что те, кто не осилили парсер не побьют память, ведь их общийуровень понимания крайне низок Опять вы со своей чушью. Так и будете таскать свои глупости из поста в пост, в надежде, что никто не будет вникать? Ну-ну, продолжайте... Посмотрим, чем это закончится.
	Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

	359. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 23:34
	>в надежде, что никто не будет вникать Как вижу, вы до сих пор не поняли в чём проблема, и не поправили парсер
	Ответить | Правка | Наверх | Cообщить модератору

	366. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 19-Сен-24, 00:16
	> Как вижу, вы до сих пор не поняли в чём проблема, и > не поправили парсер Ну так расскажите)) А то я от вас ничего, кроме всякого бреда, пока что-то не видел. Про производительность, если что, можете сказки сразу не рассказывать - тестировалось это всё на 500+ Гб файлов, результат - вполне удовлетворительный. Утечек памяти нет, ошибок - тоже. По крайней мере с февраля жалоб не поступало. У меня у самого нареканий тоже нет. Со скоростью работы там есть проблемы, но отнюдь не в парсере, а в той части, что работает с архивами. Вот там - да, есть ещё над чем поработать. Да и дело то не в этом. Я тоже человек, вполне могу ошибиться - мои программы не истина в последней инстанции. Дело в том, что вы тут проповедуете, какими методами и для чего. Как иллюстрация - вторая ссылка, которую вы тут из поста в пост таскаете. Повторю ещё раз - там проблема банальна и проста. Функция в случае ошибки возвращает -1. И если вы не проверите на минус единицу, то естественно у вас будут проблемы. В программировании оно везде так - любая мелочь имеет значение, потому что любой символ - это вполне определённые машинные инструкции.
	Ответить | Правка | Наверх | Cообщить модератору

	368. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 00:47
	>Про производительность, если что, можете сказки сразу не рассказывать - тестировалось это всё на 500+ Гб файлов, результат - вполне удовлетворительный Удовлетворительный результат - это понятие весьма растяжимое. >Утечек памяти нет, ошибок - тоже. По крайней мере с февраля жалоб не поступало Я не будут перечислять все проблемы заново, но ещё раз повторюсь, у вас нет совместимости со всей семантикой xml. Банально код <tag attr1="attr3" attr2="val1" attr3="val2"/> ваш парсер не сможет разобрать. И подобных примеров, когда ваш парсер будет работать неправильно - куча. Если вам повезло, и подобные строки не встретились, это всё ещё не говорит, о том, что ваш парсер работает нормально >В программировании оно везде так Как раз для таких случаев и придумали алгебраические типы данных, если уж исключения бросать не хочется. Там не получится случайно передать ошибку в другую функцию - только намеренно.
	Ответить | Правка | Наверх | Cообщить модератору

	373. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 19-Сен-24, 02:34
	> Удовлетворительный результат - это понятие весьма растяжимое. Нет, не растяжимое. Задача была - создать программу, которая будет собирать базу данных из различных типов электронных книг и архивов любой глубины. Вторая задача - организовать поиск по этой базе данных по определённым критериям и открытие найденных файлов. Именно это программа и делает. Это называется "удовлетворительный результат". Хорошим он станет, когда удастся избежать крахов на rar архивах, а также улучшить кое-какие мелочи. С rar архивами проблема, потому что падает библиотека libarchive, а не сама программа. Падает во вполне конкретном месте - оно мне известно. Временные пути обхода сделаны, багрепорт в libarchive висит. На этом мои возможности заканчиваются. Можно конечно написать реализацию распаковки rar архивов самому, но на это у меня нет времени. И нет желания - формат проприетарный, используется по большей части в Windows. Программа же в первую очередь предназначена для пользователей Linux, бодаться с юристами по поводу возможных проблем с лицензиями и раскапывать спецификации формата не вижу никакого смысла. В том числе потому, что не было задачи написать полноценный архиватор. Распаковка архивов - лишь бонус к основным функциям программы. Там и так пришлось костыль для zip архивов написать, чтобы ускорить их обработку. > Я не будут перечислять все проблемы заново, но ещё раз повторюсь, у > вас нет совместимости со всей семантикой xml. Банально код <tag attr1="attr3" > attr2="val1" attr3="val2"/> ваш парсер не сможет разобрать. И подобных примеров, когда > ваш парсер будет работать неправильно - куча. Если вам повезло, и > подобные строки не встретились, это всё ещё не говорит, о том, > что ваш парсер работает нормально Как раз это и говорит, о том, что программа работает нормально. Цели реализовать полноценный парсер xml не было. Реализовано только то, что встречается в форматах fb2 и ebub, в соответствии с их документацией. Реализовано опять же не полностью, потому что не было задачи отображать весь текст, стояла задача лишь добиться корректного отображения общей информации о книгах. И задача достигнута. Если возникнет такая необходимость, то парсер легко может быть адаптирован для полноценной работы с xml. > Как раз для таких случаев и придумали алгебраические типы данных, если уж > исключения бросать не хочется. Там не получится случайно передать ошибку в > другую функцию - только намеренно. Алгебраические типы данных придумали для того, чтобы работать с большими числами в первую очередь. Там, где это требуется, например - в научных расчётах. Потому что у всего есть цена. Если вы работаете с алгебраическими типами данных, то платите за это повышенным расходом памяти и снижением быстродействия. Т.к. данные хранятся в оперативной памяти, а не в стеке (есть естественно нюансы, я их сознательно сейчас опускаю). И во многих процессорных архитектурах специально предусмотрены инструкции для работы с типами данных фиксированной длины. А алгебраические типы данных - это всегда реализация на уровне софта, а не железа. И никаким преимуществом алгебраические типы данных не являются, поскольку если речь идёт о C/C++, то много лет уже существует библиотека gmp, в которой всё это реализовано. А также есть куча математических функций для работы с алгебраическими данными. Кроме того, нет никаких проблем написать всё это самому - я знаю, я делал. Чисто для тренировки, работало на базе std::vector<bool>. То же самое можно реализовать с помощью std::bitset или с помощью массивов char. Ну а приведённая вами ссылка и вовсе ко всему этому не имеет никакого отношения, поскольку там функция может в случае ошибки вернуть -1. И возвращаемое значение нужно проверять, иначе ничего хорошего не получится. Хоть с алгебраическими типами данных, хоть без них.
	Ответить | Правка | Наверх | Cообщить модератору

	375. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 03:16
	>Алгебраические типы данных придумали для того, чтобы работать с большими числами в первую очередь Что? У вас какое-то своё собственное понимание данного термина. Алгебраические типы данных, это например type 'a option =   | None   | Some of 'a >Реализовано опять же не полностью Наконец-то мы договорились. >потому что не было задачи отображать весь текст Мне всё равно непонятно, зачем нужны такие костыли >Если вы работаете с алгебраическими типами данных, то платите за это повышенным расходом памяти и снижением быстродействия Вы уверены, что сможите заметить различие в объёме данных, которые возвращает fork? >Т.к. данные хранятся в оперативной памяти, а не в стеке Стек тоже хранится в оперативной памяти. >А алгебраические типы данных - это всегда реализация на уровне софта, а не желез Откуда такой вывод? >то много лет уже существует библиотека gmp Это вообще не то >Ну а приведённая вами ссылка и вовсе ко всему этому не имеет никакого отношения, поскольку там функция может в случае ошибки вернуть -1 В си сигнатура fork int fork() В rust сигнатура pub enum Fork {     Parent(pid_t),     Child, } pub fn fork() -> Result<Fork, i32> Вы просто физически не сможете в pid_t засунуть результат fork-а в rust, у вас будет ошибка, что типы pid_t и тип Result<Fork, i32> различаются. match fork() {    Ok(Fork::Parent(child)) => {        println!("Continuing execution in parent process, new child has pid: {}", child);    }    Ok(Fork::Child) => println!("I'm a new child process"),    Err(_) => println!("Fork failed"), } В ocaml есть исключения, и fork их кидает. >Хоть с алгебраическими типами данных, хоть без них. Хорошо, с парсером разобрались, что такое алгебраические типы данных я вам объяснил, что ещё вы понимаете не так?
	Ответить | Правка | Наверх | Cообщить модератору

	294. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 15:12
	> Есть огромная разница между добавлением новой семантики и новым апи. И где кроме 11 стандарта как-то в корне меняли семантику? Ты не переживай, раст это не про стабильность компилятора, там семантику сменят и узнаешь об этом по сломаной сборке.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	303. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (310), 18-Сен-24, 17:02
	>И где кроме 11 стандарта как-то в корне меняли семантику? А зачем её менять в корне? Достаточно добавить каких нибудь модулей
	Ответить | Правка | Наверх | Cообщить модератору

	312. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 17:32
	>>И где кроме 11 стандарта как-то в корне меняли семантику? > А зачем её менять в корне? Достаточно добавить каких нибудь модулей И в чем проблема? Ну ты реально пытаешься, что-то доказать, но сам кажется до конца не понимаешь что именно.
	Ответить | Правка | Наверх | Cообщить модератору

	346. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 19:25
	>И в чем проблема? Проблема в понимании c++ кода. Огромное количество фич, и у каждой фичи есть свои особенности. Возможно, новые способы отстрелить ногу.
	Ответить | Правка | Наверх | Cообщить модератору

	208. Скрыто модератором	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:07
	> Некоторые пишут на си с классами, теряя часть гарантий плюсов, типа умных указателей. Ну Кармак так id tech 4 написал, а растоманы за 14 лет не шмогли. Может дело в чем-то другом?
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	209. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:10
	> Время компиляции: в плюсах есть десятки разных способов затормозить компиляцию, начиная с возможности инклюдить произовльные файлы в произвольные места То есть ты предлагаешь СПЕЦИАЛЬНО делать ерунду и говорить что все плохо?
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	222. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 04:20
	>СПЕЦИАЛЬНО делать ерунду Во-первых, хорошие языки ерунду не компилируют, а пишут ошибку. Во-вторых, я крайне сомневаюсь, что в команде хромиума сидит злодей и внедряет пакости. Просто компилятор плюсов тормозит из-за сложности последних
	Ответить | Правка | Наверх | Cообщить модератору

	290. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 14:54
	Нужно переписать весь хромитам на раст и померить время сборки на холодную. А без этого твои слова ничем не доказуемы. У них много кода, вот он долго и компилится первый раз. К слову в расте раньше не было инкрементальной сборки и Дропбокс плакался по этому поводу достаточно сильно.
	Ответить | Правка | Наверх | Cообщить модератору

	299. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (310), 18-Сен-24, 16:46
	>Нужно переписать весь хромитам на раст У вас болезненная зацикленность на расте? >А без этого твои слова ничем не доказуемы. Вы не видите очевидных доказательств. Вот один из примеров https://www.opennet.ru/opennews/art.shtml?num=56475 >У них много кода, вот он долго и компилится первый раз. Нет, это сишники не осилили нормальный компилятор. Запрети циклические зависимости, и проблема выше решится сама собой, без необходимости строчить огромные патчи. А даже если патч примут, то снова разведут бардак.
	Ответить | Правка | Наверх | Cообщить модератору

	328. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:38
	Зато сишники освоили более одного production-ready компилятора, и все благодаря наличию стандарта.
	Ответить | Правка | Наверх | Cообщить модератору

	329. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:41
	>>Нужно переписать весь хромитам на раст > У вас болезненная зацикленность на расте? Критикуя, предлагай. с++ единственный вариант для хромиума. Кода много, поэтому и компилится долго. Просто это овердофига большой проект. Возможная замена - это раст. Но как сильно изменится время компиляции? Попробуй собери что ли компилятор раста или firefox и сравни. >>А без этого твои слова ничем не доказуемы. > Вы не видите очевидных доказательств. Вот один из примеров https://www.opennet.ru/opennews/art.shtml?num=56475 Нашел новые?) Могу еще подсказать поискать новости про то, что в ядре повторяется куча кода в разных подсистемах. >>У них много кода, вот он долго и компилится первый раз. > Нет, это сишники не осилили нормальный компилятор. Запрети циклические зависимости, и проблема > выше решится сама собой, без необходимости строчить огромные патчи. Ну ты же не пишешь на си и с++ как ты говоришь. Почему ты судишь осили кто-то или нет? > А даже если патч примут, то снова разведут бардак. Попробуй посопровождай проект подобного уровня и посмотрим какой там будет бардак. Чел, это не бардак)
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

	348. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 19:38
	>Кода много, поэтому и компилится долго Вы ссылку читали? >При использовании Clang применение патчей позволило сократить время сборки на 88% или на 77% Функционал остался тем же, но собираться стал более чем в четыре раза быстрее >Критикуя, предлагай Я ясно сказал, что нужно сделать: запретить циклические зависимости, хотя бы на уровне линтера. Вот вам Ocaml https://wiki.xenproject.org/wiki/OCaml_Cyclical_Build_Depend... Слышал, что в делфи аналогично, но утверждать не берусь. >Почему ты судишь осили кто-то или нет? Потому, что когда я создал подобную проблему в Ocaml, в гораздо меньшем масштабе, то компилятор меня сразу же предупредил. При работе с Ocaml периодически чувствуешь, как компилятор активно мешает писать плохой код, в то же время, когда я собирал си/плюсы, то компиялторы собирали абсолютно любой синтаксически корректный говнокод. >Чел, это не бардак) Вот в этом то и проблема. Сишники/крестовики будут отказываться признавать наличие проблемы. Ну и что, что время компиляции растягивается, типичный сишник и не знает, что компиляция может быть быстрой.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 23:36
	> При работе с Ocaml периодически чувствуешь, как компилятор активно мешает писать плохой код, в то же время, когда я собирал си/плюсы, то компиялторы собирали абсолютно любой синтаксически корректный говнокод. Зачем сравнивать функциональный язык с GC и императивный без GC? Блин, да для ocaml даже нормальной gui библиотеки нет. Ну что-то браузера на ocaml не видел, хотя вот на common lisp есть.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 00:00
	>Зачем сравнивать функциональный язык с GC и императивный без GC? А какая разница? Почему нельзя запретить циклические ссылки на исходники в империативном языке?
	Ответить | Правка | Наверх | Cообщить модератору

	361. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 23:40
	> Вот в этом то и проблема. Сишники/крестовики будут отказываться признавать наличие проблемы. > Ну и что, что время компиляции растягивается, типичный сишник и не > знает, что компиляция может быть быстрой. Никто не отказывается ничего признавать. Ее решают по другому просто. Я тебе еще раз говорю: возьми свой любимый яп, возьми проект уровня хромиума (по кол-ву кода) и покажи мне время сборки для него. Ну только чтобы без рантайма яп был.
	Ответить | Правка | К родителю #348 | Наверх | Cообщить модератору

	367. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 00:21
	>Ее решают по другому просто Как решают? Периодически патчи присылают, как с linux? Это не решение проблемы языка, это исправление одного единственного проекта. Для freebsd нужно будет начинать с нуля. >возьми проект уровня хромиума (по кол-ву кода) и покажи мне время сборки для него Вопрос не в количестве строк как таковых(тут да, chromium - рекордсмен). Вопрос в том, что существуют короткие примеры, порой меньше сотни строк, которые растягивают время компиляции в несколько раз, а то и на несколько порядков. К сожалению не могу найти статью про c++, вот пример со swift https://habr.com/ru/articles/283106/ >Ну только чтобы без рантайма яп был. У плюсов есть рантайм.
	Ответить | Правка | Наверх | Cообщить модератору

	370. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 01:49
	>>Ее решают по другому просто > Как решают? Периодически патчи присылают, как с linux? Это не решение проблемы > языка, это исправление одного единственного проекта. Для freebsd нужно будет начинать > с нуля. Кэш, распределенная сборка.
	Ответить | Правка | Наверх | Cообщить модератору

	372. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 02:02
	>Кэш Я не помню точных цифр, но вместе с кешем хромиум собирался не больше суток, а часов за шесть, что всё равно много.
	Ответить | Правка | Наверх | Cообщить модератору

	371. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 01:59
	Нашёл пример для плюсов https://habr.com/ru/companies/jugru/articles/438260/ >Время компиляции этого реально наипростейшего примера заняло на 2.85 секунды дольше, чем версия с «простым C++». >Например, за какое время clang сможет скомпилировать настоящий полноценный движок базы данных (SQLite) в отладочном режиме, включая все 220 тысяч строчек кода? За 0.9 секунд на моём ноутбуке.
	Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

	334. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:50
	> это сишники не осилили нормальный компилятор Для си есть верифицированный компилятор https://compcert.org/, компиляторы попроще tcc (используется для бутстрапинга) и куча других проектов. Так что тут не прав. Выбор - это всегда хорошо.
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

	210. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:12
	>  Часть проектов будут сочетать в себе безопасные и небезопасные части, при этом любой коммит будет менять их в произвольные стороны У нормальных проектов есть различные чекеры (тот же clang-tidy, который можно настроить на следование различныи фичам) и ревью. А проблема, которую ты описываешь - это общая проблема всех развивающихся во времени систем.
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	223. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (175), 18-Сен-24, 04:27
	>У нормальных проектов есть различные чекеры Вот вы и назвали важный недостаток. Нужно, чтобы повезло и в проекте оказался анализатор, чтобы договорились включить диагностику, чтобы если диагностика выдаст пару сотен тысяч ошибок её не отключили, чтобы библиотеки тоже проверялись и так далее. И редко, когда всё совпадает. Вот когда анализатор встроен в язык, тогда всё работает из коробки. В реальности же целый гугл не смог реализовать парсер json, и им пришлось брать его из раста
	Ответить | Правка | Наверх | Cообщить модератору

	291. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 14:58
	> Вот вы и назвали важный недостаток. Нужно, чтобы повезло и в проекте оказался анализатор, чтобы договорились включить диагностику, чтобы если диагностика выдаст пару сотен тысяч ошибок её не отключили, чтобы библиотеки тоже проверялись и так далее. Если у тебя в этом месте проблемы, то и срастом такие же будут. Кто будет следить, что я не расставляю ансейфы для обхода борова? Кто будет следить, что я не подключаю левые либы? Итд итп. К слову даже в расте есть клиппи, а это отдельная тулза. > В реальности же целый гугл не смог реализовать парсер json, и им пришлось брать его из раста Бред.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (295), 18-Сен-24, 16:42
	> Кто будет следить, что я не расставляю ансейфы для обхода борова? Тут два варианта - у вас есть код-ревью или ты сам себе хозяин.   Если на код-ревью у тебя в растовском коде увидят сотни/тыщщи участков с ансейфом, к тебе возникнут вопросы. Почитают комментарии к этим участкам кода, присмотрятся, подумают, насколько это оправданно и заствят переписать. Повторится - скорее всего выкинут на улицу как диверсанта или неосилятора.   Ну а если ты сам себе начальник, то, получается, сам себе в штаны накладываешь и вообще не будет разговора об "кто следить будет" - сам себя обманываешь.
	Ответить | Правка | Наверх | Cообщить модератору

	330. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:42
	Ну так это работает и с C++. Есть кому следить за использованием анализатора кода - будет толк, нету - сам себе злобный буратино и никакой раст не спасет.
	Ответить | Правка | Наверх | Cообщить модератору

	331. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:43
	>> Кто будет следить, что я не расставляю ансейфы для обхода борова? > Тут два варианта - у вас есть код-ревью или ты сам себе > хозяин. Ну дык в проекте на с++ также. >   Если на код-ревью у тебя в растовском коде увидят сотни/тыщщи > участков с ансейфом, к тебе возникнут вопросы. Почитают комментарии к этим > участкам кода, присмотрятся, подумают, насколько это оправданно и заствят переписать. > Повторится - скорее всего выкинут на улицу как диверсанта или неосилятора. Тоже самое для проекта на ___ (подставь что хочешь).
	Ответить | Правка | К родителю #298 | Наверх | Cообщить модератору

	301. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (310), 18-Сен-24, 16:53
	>Если у тебя в этом месте проблемы, то и срастом такие же будут При чём тут раст? И да, в расте это делатся явно и проверяется примитвно, банальным grep. В плюсах вручную перелопачивать миллионы строк >Бред Вашемнение реальность не изменит, а аргументов от вас нет
	Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

	333. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:47
	>>Если у тебя в этом месте проблемы, то и срастом такие же будут > При чём тут раст? И да, в расте это делатся явно и > проверяется примитвно, банальным grep. В плюсах вручную перелопачивать миллионы строк Зачем перелопачивать миллионы строк. Можно достаточно быстро увидеть как в проекте ведется работа с памятью, используются ли умные указатели, раи или они пишут как на си и жанглируют сырыми. >>Бред > Вашемнение реальность не изменит, а аргументов от вас нет Чел, ты видимо не переписывал большие проекты. Никто не будет переписывать на раст сложные подсистемы в хроме, а начнут с чего пропроще. Генерато qr кодов там или вот парсер json. Потому что повесточка такая от начальсва, а глупцам наружу скажут, что безопасно. Ну по CVE парсер json явно не на 1-ом месте.
	Ответить | Правка | Наверх | Cообщить модератору

	362. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 23:49
	>Можно достаточно быстро увидеть как в проекте ведется работа с памятью, используются ли умные указатели, раи или они пишут как на си и жанглируют сырыми Интересно и как? Вот в расте - понятно, берём grep unsafe -rn и готово. В языках с GC скорее всего искать не нужно. Может быть ещё несколько ключей добавить. Что вместо unsafe подставлять в grep? Звёздочку - как мне отличить умножение от разыменновывания? Это уже не grep нужен, а какой-то специализированный инструмент. malloc искать? Но это не поможет, если кто то прошолся по коду, и заменил malloc на new, free на delete. Просмотреть пару файлов? А остальные как? >Никто не будет переписывать на раст сложные подсистемы в хроме >а глупцам наружу скажут, что безопасно Давайте посмотрим, что в новости: >Отмечается, что переход на новый парсер может привести к прекращению разбора некоторого некорректно оформленного контента в формате JSON, но при этом он также решает проблемы при работе с некорректным JSON, который раньше вызывал аварийное завершение, а теперь приводит к возврату кода ошибки. То есть во-первых, старый парсер не следовал спецификации JSON, а во-вторых, вызывал аварийное завершение. Вы считаете нормальным, что парсинг такого простого формата выполняется так криво?
	Ответить | Правка | Наверх | Cообщить модератору

192. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
Сообщение от maxis11 (ok), 17-Сен-24, 23:00
Я так и не понял почему надо создавать новый продукт, если можно подключить clang-tidy в CI/CD с проверкой на cppcoreguidelines-owning-memory (можно ещё кучу дополнительных проверок взять)? Суть такова: в CI/CD добавить этап, который будет блокировать PR изменений если они не прошли проверку линтера, зе энд.
Ответить | Правка | Наверх | Cообщить модератору

	202. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (201), 18-Сен-24, 00:58
	> clang-tidy Это отдельная тулза. Нужно в стандарте чтобы что-то было прямо в компиляторе.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (295), 18-Сен-24, 16:47
	Гуглу всякие "анализаторские" инструменты и фаззинг-тестирования не помогают в сишных/плюсовых проектах, всё равно ошибки просачиваются. Потому они и нахваливают раст и горлапанят о желании всю новую или ответственную нативную системщину в андроиде писать на расте.
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	332. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:45
	Вот именно что нахваливают и горланят, но переходить не торопятся.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:52
	> о желании всю новую или ответственную нативную системщину в андроиде писать на расте На фучсии они также делали, но с++ там тоже дофига был (задание подумать почему). И где теперь фучсия?
	Ответить | Правка | К родителю #300 | Наверх | Cообщить модератору

212. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
Сообщение от Аноним (212), 18-Сен-24, 01:29
вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ? или вообще все без задней мысли как все работает ? капец просто, сколько это уже можно мусолить.
Ответить | Правка | Наверх | Cообщить модератору

	215. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (215), 18-Сен-24, 02:27
	Опять про Настоящих Сишников™®© заливает. У Линуса спроси, он разъяснит как они там тридцать лет в ядре по этим граблям зодят и конца-края этому не видно.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (218), 18-Сен-24, 03:17
	Он наверное про RAII.
	Ответить | Правка | Наверх | Cообщить модератору

	229. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (229), 18-Сен-24, 07:17
	std::shared_ptr<Твой суперский тип> и все, как только исчезнут владельцы ссылок на объект он освободится. Прям капец трудно, дааа ? 1000 страниц прочитать надо, даааа ? Для клас-обертка вокруг ресурса с освобождением в деструкторе тоже пишется без каких-либо проблем... раст делает это "по умолчанию" с++ делает только то о чем его явно попросили. Затем статческий анализ не позволит васяну использовать чистые указатели и ресурсы без обертки с деструктором. Все загоны растоманов от не знания базовых вещей, что етсь в с++ с 11 стандарта.
	Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

	272. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (241), 18-Сен-24, 10:27
	> std::shared_ptr<Твой суперский тип> и все, как только исчезнут владельцы ссылок на объект он освободится. > Все загоны растоманов от не знания базовых вещей, что етсь в с++ с 11 стандарта. Лол. Если бы у тебя было знание базовых вещей C++, то был бы в курсе, что проблема владения не ограничивается возней с heap и RAII. Это проблема в дырявом фундаменте языка. Как твой shared_ptr поможет в этом: auto a = 0; auto& b = std::max(a, 1); Вот у тебя b - висячая ссылка. > с++ делает только то о чем его явно попросили. C++ ничего не делает.
	Ответить | Правка | Наверх | Cообщить модератору

	337. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:53
	А ты делай так: auto a = std::make_shared<int>(0); auto b = std::max(*a, 1); C++ ничего не делает за ленивых программистов.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Facemaker (?), 18-Сен-24, 13:21
	>от не знания базовых вещей Вот эта вот системная безграмотность очень красноречива.
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	307. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (310), 18-Сен-24, 17:21
	> std::shared_ptr<Твой суперский тип> и все, как только исчезнут владельцы ссылок на объект он освободится. Простейший двусвязный список и объект застрял навечно. А если это подкостылить слабыми ссылками, то уже можно получить висячий указатель
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	335. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:51
	Если так старатся, то можно и ошибку памяти в Rust организовать https://github.com/Speykious/cve-rs
	Ответить | Правка | Наверх | Cообщить модератору

	350. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 19:43
	>Если так старатся Что значит стараться? Условный студент по вашему специально ошибки в курсовую вносит?
	Ответить | Правка | Наверх | Cообщить модератору

	249. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (249), 18-Сен-24, 09:14
	Ну верит человек до сих пор в Деда мороза, - пускай и дальше верит!:)
	Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

	245. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (249), 18-Сен-24, 09:07
	>>> запросил памяти отработал, освободил. кто отменил культуру написания кода ? <<< Это хорошо звучит только в теории, на практике это не работает, - просто смиритесь с этим! Rust придумали не просто так!!!
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	253. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (250), 18-Сен-24, 09:28
	Конечно не просто так, а из-за NIH.
	Ответить | Правка | Наверх | Cообщить модератору

	251. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (250), 18-Сен-24, 09:23
	При этом котроль выхода за границы массива, как бы, не помешает.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	273. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (241), 18-Сен-24, 10:32
	> вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ? Не понимаешь потому, что проблема владения не ограничивается возней с new/delete. В плюсах ты можешь в это вляпяться вообще без динамического выделения памяти.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	277. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (249), 18-Сен-24, 11:09
	Да, забей! Таким бесполезно что-то объяснять; cразу видно, что человек никогда не писал ничего серьёзного на С++, иначе он бы не писал глупости в стиле - да это же элементарно! ПС: Лично у меня бывали случаи когда приходилось писать код по 10, а то и по 12 часов в день. В таких случаях, лично я предпочту компилятор rustc, который скажет мне если я, скажем на 10 часу, когда я устал и моя концентрация упала, попытаюсь сделать какую-нибудь "элементарную" глупость, что я не прав, где именно, в чём не прав и самое главное как это исправить, вместо того, чтобы разбираться в "шаблонных портянках C++" из серии - упс извините, но "что-то" не так!
	Ответить | Правка | Наверх | Cообщить модератору

	279. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (112), 18-Сен-24, 11:24
	Только на раст для той же работы тебе понадобится 60 часов. Но да компилятор тебе точно скажет и много плохих слов про себя от него узнаешь.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (281), 18-Сен-24, 11:40
	> Только на раст для той же работы тебе понадобится 60 часов. Ты наверное написал тысячи строк на Расте, раз так уверенно утверждаешь. Хотя, скорее всего, ты не написал ни одной. У гугла как-то получается, что раст-команды продуктивнее чем плюсовики. Но туда конечно не васянов с улицы берут. > да компилятор тебе точно скажет и много плохих слов про себя от него узнаешь. Компилятор не анон, он если ругается - то по делу.
	Ответить | Правка | Наверх | Cообщить модератору

	339. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:56
	"Сначала добейся", и сразу ссылка на авторитет. Просто ходячая демагогия.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (249), 18-Сен-24, 11:45
	>>> Только на раст для той же работы тебе понадобится 60 часов. <<< Разумеется в С++ есть херова туча библиотек почти на все случая жизни в отличии от Раста, - и именно поэтому вам кажется что писать код на плюсах быстрее, - и это нормально! Однако, если вы Раст не знаете, то вполне возможно вам и этого будет мало (и как это часто и бывает) вы вообще ничего не напишите!
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

	340. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (314), 18-Сен-24, 18:59
	но люди не поэтому пишут статьи "Почему я отказался от разработки игр на Rust"
	Ответить | Правка | Наверх | Cообщить модератору

	379. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Проходил мимо (?), 19-Сен-24, 07:35
	Уважаемый анонимный иксперд, довожу до вашего сведения, что настолько большой разницы в скорости написания сферического кода в вакууме на Си, Си++, GoLang и Rust нет от слова совсем. Хотя, в некоторых случаях, вам потребуется гораздо меньше времени для написания кода на Rust, но это касается тех случаев, когда что-то, реализованное в стандартной библиотеке Rust, отсутствует в стандартной библиотеке Си++ либо сделано там через жопу. Стандартная библиотека GoLang в этом отношении еще круче, особенно в плане обработки связанных с вебом вещей и генерации страниц по шаблонам.
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

	288. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аниним (?), 18-Сен-24, 14:20
	> ПС: Лично у меня бывали случаи когда приходилось писать код по 10, а то и по 12 часов в день. В таких случаях, лично я предпочту компилятор rustc А йа лучше меньше часов попрогаю :)
	Ответить | Правка | К родителю #277 | Наверх | Cообщить модератору

	320. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (29), 18-Сен-24, 18:04
	я даже не представляю, что можно прогать 12 часов, кек
	Ответить | Правка | Наверх | Cообщить модератору

	306. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (310), 18-Сен-24, 17:18
	>вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ? или вообще все без задней мысли как все работает ? Вы не знаете про существование кучи? Где вы там память освобождать собрались?
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	322. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (29), 18-Сен-24, 18:08
	> Вы не знаете про существование кучи? программист на "высокоуровневом безопасТном ЯП" - знать не должен!
	Ответить | Правка | Наверх | Cообщить модератору

	352. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 20:03
	>программист на "высокоуровневом безопасТном ЯП" - знать не должен! Зато плюсовики просто обязаны
	Ответить | Правка | Наверх | Cообщить модератору

265. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от n00by (ok), 18-Сен-24, 09:51
Таким образом дальше может возникнуть подозрение, что кого-то после знакомства с OCaml посетила гениальная идея сделать члены class по умолчанию const и перенести часть работы сборщика мусора на этап трансляции. Но потом что-то пошло не так и автор Rust нарулил из проекта.
Ответить | Правка | Наверх | Cообщить модератору

338. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
Сообщение от nc (ok), 18-Сен-24, 18:55
У меня проблем с памятью в С++ вообще не было, хотя и смартпоинтерами практически не пользуюсь, и отслеживание владения объектами мне как-то не требуется - объекты просто не меняют владельца в течение всего времени жизни. А вот чего не хватает, так это рефлексии и императивных синтаксических макросов.
Ответить | Правка | Наверх | Cообщить модератору

	351. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 18-Сен-24, 20:01
	>У меня проблем с памятью в С++ вообще не было Откуда вы это знаете? Фазеры, например, находят неочевидные проблемы
	Ответить | Правка | Наверх | Cообщить модератору

342. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от Аноним (342), 18-Сен-24, 19:12
Это уже можно назвать Rust с классами?
Ответить | Правка | Наверх | Cообщить модератору

347. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от Аноним (314), 18-Сен-24, 19:35
Безопасная работа с памятью и 100% совместимость с существующей кодовой базой. И даже специалистов не нужно переучивать на новый язык. Что еще нужно для счастья.
Ответить | Правка | Наверх | Cообщить модератору

	353. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 18-Сен-24, 20:41
	> даже специалистов не нужно переучивать на новый язык Ага, мечтай. У них в драфте есть пример: int main() safe {   std2::vector<int> vec { 11, 15, 20 };   for(int x : vec) {     // Ill-formed. mutate of vec invalidates iterator in ranged-for.     if(x % 2)       mut vec.push_back(x);     std2::println(x);   } } Невозможность мутабельно работать с vec, если у тебя есть активный итератор овер vec. В этом примере, может не очень видно, насколько это большое препятствие для мозгов воспитанных на C и C++, но я заверяю тебя, крутизна кривой обучения расту для C/C++ программистов в основном так закручивается благодаря вот именно этой фишке. В терминах раста, итератор борроуит vec, и поэтому сам vec не может быть использован через мутабельную ссылку. Если итератор мутабельный, то он мутабельно борроуит vec, а это значит что даже немутабельные обращения к vec запрещены борроу-чекером. Но это цветочки, ягодки дальше: селфреференшл структуры становятся запрещёнными компилятором. Например, циклические списки. Или если ты хочешь создать структуру в которой будет буфер и указатель внутрь буфера, то опять же у тебя не выйдет это без unsafe. C/C++ программисту приходится учиться программировать заново, чтобы научиться писать программы при таких ограничениях. Очень интересно посмотреть, что из этого выйдет в результате. Когда C/C++ программист оказывается в расте, он испытывает сильное давление культуры, запрещающее ему пользоваться unsafe. Иногда это давление культуры выливается в давление бескультурья, когда растоманы накидываются на бедного программиста, и начинают его чмырить за обилие unsafe'ов. Результатом этого получается то, что программист постоянно преодолевает свои ограничения, и через полгода-год научается писать код так, чтобы не биться с борроу-чекером. Но с псевдо-растом, реализованном нашлёпкой поверх C++, может получиться иначе, поскольку не будет столь мощного давления нацеленного на отказ от unsafe. Вероятно это приведёт к тому, что на этом псевдорасте будет больше unsafe кода написано, и я это было бы круто. Растоманам бы не помешали бы примеры тому, как надо использовать unsafe, чтобы избегать нагораживать конструкции-франкенштейны из типов, только для того, чтобы избежать чутка ансейфа. На мой взгляд, они выбрали избыточно параноидальный компромисс между "safe + даёптваюмать-сколько-можно-типов-плодить" и "unsafe и просто и понятно". Растоманский компромисс не дотягивает до отмороженности того, что в начале 00 C++-программисты творили под разлагающим влиянием Александреску, но примерно в ту сторону. В общем, я желаю успехов данному начинанию, если получится, оно сделает раст ещё лучше.
	Ответить | Правка | Наверх | Cообщить модератору

355. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от Аноним (-), 18-Сен-24, 22:09
NVIDIA пишет драйвер на Rust, но тут многим виднее... https://lists.freedesktop.org/archives/dri-devel/2024-March/...
Ответить | Правка | Наверх | Cообщить модератору

	356. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 18-Сен-24, 22:11
	точнее RedHat
	Ответить | Правка | Наверх | Cообщить модератору

363. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от Другой Аноним (?), 18-Сен-24, 23:50
Есть всего одна простая опция как радикально повысить безопасность C++ - отбросить поганое наследие Си: - char* в коде?  Ошибка, остановка компиляции. - memcpy в коде? Ошибка, остановка компиляции. - malloc/free в коде? Ошибка, остановка компиляции. - сишное преобразование переменных? Ошибка, остановка компиляции. и.т.п. Всё, безопасность вашего кода улучшена многократно.
Ответить | Правка | Наверх | Cообщить модератору

	369. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 00:48
	Этого не хватит - останется как минимум ошибка на миллиард долларов - null.
	Ответить | Правка | Наверх | Cообщить модератору

	374. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (374), 19-Сен-24, 03:00
	Если запретить хранить "сырые" указатели, то нужно очччень постараться чтобы сломать себе ногу о nullptr. Так и на автомобиле можно в дерево въехать если очень захотеть. Вообще ошибки с nullptr - самые простые для отлова и исправления, всегда понято где навернулось и почему.  В отличие от того же use-after-free, от которого у сишных программистов на лбу уже должна быть вмятина по форме ручки от грабель. Вот последнее реально на миллиард долларов.
	Ответить | Правка | Наверх | Cообщить модератору

	376. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 03:29
	>Вообще ошибки с nullptr - самые простые для отлова и исправления, всегда понято где навернулось и почему. Нет, же, нет. Даже мне, человеку не пишущему на c++ известно, что a[b] аналогично *(a+b). И если взять достаточно большой массив, то в итоге адресной арифметики хватит, чтобы указатель вышел за несколько первых зарезервированных страниц памяти и влез в чужую память. Насколько мне известно, это не единственный вариант
	Ответить | Правка | Наверх | Cообщить модератору

	377. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (374), 19-Сен-24, 05:41
	> что a[b] аналогично *(a+b) Есть такое, да. Только это не проблема null, а buffer overflow. Может придумают что с этим делать, как решили проблему use-after-free и владения памятью. Пока что есть range based for и всякие отладочные костыли.
	Ответить | Правка | Наверх | Cообщить модератору

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

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