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

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

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

	385. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–2 +/–
	Сообщение от adolfus (ok), 19-Сен-24, 12:22
	Смишно. Этот альянс -- сборище жуликоватых хитрованов. Зарегистированы, как торговая организация с очень интересными правами -- донаты юридических и физлиц не облагаются налогами, плюс исключаются из налогооблагаемой базы донатящих.Ну и фоты на интернет-простыне -- к ак говорится, бог шельму метит.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	422. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от pavlinux (ok), 20-Сен-24, 13:11
	> Смишно. Этот альянс -- сборище жуликоватых хитрованов. The C++ Standards Committee - ISOCPP прокатит для твоего авторитета :D? https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34...
	Ответить | Правка | Наверх | Cообщить модератору

	452. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от adolfus (ok), 27-Сен-24, 12:27
	>> Смишно. Этот альянс -- сборище жуликоватых хитрованов. > The C++ Standards Committee - ISOCPP прокатит для твоего авторитета :D? > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... $ ping www.open-std.org PING www.open-std.org (192.38.78.170) 56(84) bytes of data. ... ждите ответа ... ждите ответа ... ждите ответа ... Даже если, и что? С 1999 года было опубликовано несколько тысяч предложений, из которых в стандарты С (9899) и С++ (14882) вошло менее процента. Даже предложение MS про "безопасные" потоковые и строковые функции "*_s", поданное к стандарту 9899-2011, было отвергнуто абсолютным большинством из-за несовместимости интерфейса cо стандартными, что они специально сделали, с целью насрать и развалить стандарт. Но из-за того, что Mammoth Shit донатит, оно таки вошло, однако существует с 2011 г. в виде приложения. В 14882 вносят только то, что действительно повышает безопасность, а не понижает уровень вхождения нубов и возможность лажануться у борзопрограммеров. Повышение безопасности для снижения уровня вхождения -- тупик и комитет это четко понимает. Любые предложения в этом ключе, по крайней мере, до 14882-2017 отвергались. Более нового стандарта у меня нет, только последний драфт, поэтому оценить их не могу. Что касается "безопасности" программирования, то отказ от наследования и полиморфизма практически полностью ликвидирует проблемы с указателями, при этом производительность и компиляции и исполнения существенно растет. Проблемы с выходом за границы массивов? Ну так это логическая ошибка в чистом виде и за нее отвечает только программист. Он должен следить за тем, куда пишет и откуда читает. Кстати, оператор "[ ]" -- это синтаксический сахар для операций с указателями, о чем в стандарте четко написано. Соответсвенно, без навыков работы с арифметикой указателей с C и C++ с массивами нечего делать. Кто желает работать с массивами, не держа в уме при этом, как и что там происходит с адресами, пусть пишет свои тормоза с использованием STL. ЕНсть правило -- если функция что-то возвращает, возврат нельзя игнорировать или отдавать на откуп реакции по умолчанию. Все возвраты, особенно обернутые в исключения  в С++, должны контролироваться, Иначе уровень программиста расти не будет, сколько бы он лишнего прикладного кода вместо контрольного не написал.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	412. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от xPhoenix (ok), 20-Сен-24, 08:46
	Какое это имеет значение, если этим всё равно машины будут заниматься?
	Ответить | Правка | Наверх | Cообщить модератору

	423. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от pavlinux (ok), 20-Сен-24, 13:13
	> Какое это имеет значение, если этим всё равно машины будут заниматься? Чинить и покупать они сами себя будут?
	Ответить | Правка | Наверх | Cообщить модератору

	448. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от laindono (ok), 22-Сен-24, 17:02
	У типичной проги на расте тысячи зависимостей, суммарно миллионы строк. У типичной крестовой проги 1.5 зависимости завендорены в репозиторий. Но при этом время компиляции сравнимо.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

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

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

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

	119. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (-), 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ообщить модератору

	436. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (449), 21-Сен-24, 20:34
	>https://habr.com/ru/articles/511478/ В статье сразу же: "В предыдущей статье мы говорили о том, как избежать переписывания библиотеки на Rust, когда вам это не нужно." "Джоэл Сполски гораздо лучше меня объясняет это в статье о том, почему полные переделки проектов — плохая идея."
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

	447. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от n00by (ok), 22-Сен-24, 09:56
	А в статье "Огонь и движение" тот же Джоэль Спольски объясняет, почему (и для кого) переделки проектов - хорошие не только идея, но и дело.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+5 +/–
	Сообщение от 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ообщить модератору

	418. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (418), 20-Сен-24, 12:17
	> Причем что в дыряшке, что в плюсах int a + int b - это уже UB! О, а что нам даст rust? Он будет на всех вариантах процессоров ловить переполнение? Или будет тратить время на предварительные проверки? Каким из двух вариантов rust облажется? Или то же приемлемое для скорости UB?
	Ответить | Правка | Наверх | 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++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (-), 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ообщить модератору

	424. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от pavlinux (ok), 20-Сен-24, 13:23
	> Чистую СИшку учить может только любитель всяких некропрограмм и легаси. > Т.к даже под микроконтролееры можно писать и на плюсах и на расте. Чтоб рожать бинарники  размером с ROM? Я тя расстрою, DSP/MC и вообще embedded еще и на ассемблере пишут.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

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

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

	314. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от Аноним (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++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (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ообщить модератору

	453. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ДаНуНафиг (?), 03-Окт-24, 05:34
	Это еще дожить надо до "removed"... std::auto_ptr с момента внесения до удаления жил 19 лет в стандарте.
	Ответить | Правка | Наверх | 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++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 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ообщить модератору

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

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

	60. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от Аноним (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++ механизмы безопасной работы с ..."	–2 +/–
	Сообщение от 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ообщить модератору

	381. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Хоан Неб (?), 19-Сен-24, 11:46
	[учебники] и [спеки] - это, какбы, разные книги
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	413. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от BeLord (ok), 20-Сен-24, 09:53
	Я могу написать отчет строго по внутренним стандартам компании на 300 страниц, а могу его же написать по делу, будет 30, так и с книгами. Порог вхождения действительно растет, с учетом того, что системы усложняются, все это умножается на повесточное образование и вуаля, реальных спецов становится все меньше.
	Ответить | Правка | К родителю #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ообщить модератору

	454. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ДаНуНафиг (?), 03-Окт-24, 05:36
	У меня ощущение, что порог входа наоборот падает. Раньше без арифметики указателей ничего не сделать было, а сейчас приучились все на векторах и shared_ptr делать, где надо и где не надо...
	Ответить | Правка | К родителю #10 | Наверх | 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++ механизмы безопасной работы с ..."	–4 +/–
Сообщение от Rev (ok), 17-Сен-24, 15:00
Какой только хернёй они не занимаются, чтобы только не переходить на Раст... Не получится навязать готовому языку безопасность в виде костылей.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

	437. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (449), 21-Сен-24, 20:40
	Проблема в обратном что программистов на Rust мало среди фанатиков Rust.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	414. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от BeLord (ok), 20-Сен-24, 09:56
	Зачем, переход ради перехода? Для каждой задачи/бюджета свой инструмент. Если сегодня устроить тендер на 10 млн долларов, написание Вордпад на С++, так чтобы код был безопасным, думаете спецы не справятся?-)) А если справятся, значит С++ проблем не имеет или имеет?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	415. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 20-Сен-24, 11:04
	> Зачем, переход ради перехода? Для каждой задачи/бюджета свой инструмент. Потому что уже сейчас есть рабочий интрумент, который успешно применяется например  в андроиде. А с другой стороны - планы когда-то сделать возможно крутую штуку, но в году так 30м. > Если сегодня устроить тендер на 10 млн долларов, написание Вордпад на С++, так чтобы код был безопасным, думаете спецы не справятся?-)) Думаю нет. Посмотри какие бюджеты (можно прикинуть по средней зп на глассдоре) у таких проектов как андроид или хром. А ошибки там находят регулярно. > А если справятся, значит С++ проблем не имеет или имеет? Ну вот когда справятся, тогда и поговорим) Пока есть только такие старые данные In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. 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ообщить модератору

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

	32. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (-), 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++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (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ообщить модератору

	457. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (456), 21-Окт-24, 20:01
	Даже нового кода на расте Гугл пишет очень малую долю.
	Ответить | Правка | Наверх | 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++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (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++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (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++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (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ообщить модератору

	450. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (449), 23-Сен-24, 23:54
	Это костыль для отмазки, а не обратная совместимость. По факту старую прогу на Расте фиг соберешь без бубна.
	Ответить | Правка | Наверх | 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++ механизмы безопасной работы с ..."	+3 +/–
	Сообщение от bOOster (ok), 18-Сен-24, 08:18
	Точно. на текущий момент есть always acceptable #pragma region .... #pragma endregion .... Реализовать логику #pragma region safe/unsafe Особой проблемы нет.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	428. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (428), 20-Сен-24, 14:56
	1. Он говорит о безопасности, а не об оптимизациях, ты чего. И для опеннета можно добавить, что в линуксовой сишке это направление оптимизаций исключено (provenance-based alias analysis - это развитие type-based alias analysis, который отключён через -fno-strict-aliasing). 2. Если хочется и оптимизации в этом направлении, и безопасность в виде отсутствия UB, то мы возвращаемся в ~1989, когда в первый стандарт C добавили понятие UB без оговорок, что UB предпочтительно обнаруживать статическим анализом и предупреждать. То есть это в идеологии post-K&R C (& C++) заложено - компилятор может делать "глупые и опасные" оптимизации без предупреждений (пусть программист *сам* ищет у себя UB), потому что - видимо - в 1989 компьютеры были медленные, а компиляторщики пролоббировали свои интересы в комитете (чтобы им было меньше работы).
	Ответить | Правка | Наверх | Cообщить модератору

	429. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 20-Сен-24, 15:11
	> 1. ... в линуксовой сишке это направление оптимизаций исключено Логично, нам же нужно быстрое ядро, а не надежное. > 2. в первый стандарт C добавили понятие UB без оговорок, что UB предпочтительно обнаруживать статическим анализом и предупреждать. Насчет статического анализа ты прав, возможно мощностей и алгоритвом, тогда действительно не хватало. Но хотя бы определение UB описано достаточно нормально. > То есть это в идеологии post-K&R C (& C++) заложено - компилятор может делать "глупые и опасные" оптимизации без предупреждений (пусть программист *сам* ищет у себя UB), В стандарте есть классный раздел Conformance. В котором указывается что A strictly conforming program shall use only those features of the language and library specified in this International Standard.2) It shall not produce output dependent on any unspecified, undefined, or implemen Т.е наличе UB сразу выкидывает написанный код из этой категории. А теперь подумаем, а есть ли у нас хотя бы одна программа на СИшке без UB))? > а компиляторщики пролоббировали свои интересы в комитете (чтобы им было меньше работы). Думаю проблема была в том, что уже были написанны тонны кода с разным поведением. И никто не хотел оказаться за бортом. Чтобы никого не обидеть - постановили "на усмотрение компилятора, пусть творит что хочет".
	Ответить | Правка | Наверх | Cообщить модератору

	434. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (428), 21-Сен-24, 17:40
	> Но хотя бы определение UB описано достаточно нормально. Таки нет, потому что у него множество толкований и обоснование (в C Rationale) разошлось со сложившейся практикой. C89[1]: "Undefined behavior — behavior ... for which the Standard imposes no requirements. Permissible undefined behavior ranges from ... to ..." Часть "Permissible..." можно проигнорировать, потому что "no requirements" же (так и сделали в C99). "for which" можно истолковать как ограничение расползания UB (HDD отформатируецца, но только при исполнении строчки с UB), а можно не толковать. Обоснование говорит про "errors that are difficult to diagnose" и про расширяемость языка: "augment the language by providing a definition of the officially undefined behavior"[2]. Предложение сделать определение более человеколюбивым было[3]. C(++) здесь попали в бюрократическую ловушку. Стандарт не стимулирует компиляторщиков делать с UB что-нибудь осмысленное. Компиляторщики и не делают осмысленное, потому что стимула нет. Может, они ждали стимула со стороны (все, кто вкладывались в Ada, принесут им много денег, чтобы язык менялся в сторону большей безопасности), но за 30-35 лет не дождались, а теперь DARPA, АНБ и проч. смотрят в сторону Rust. К слову об осмысленности. Бесконечные циклы в C++ могут иметь UB, просто потому что они бесконечные[4]. Там в 1-м примере по ссылке шланг выкидывает такой цикл и вызывает функцию, которая нигде не вызывается. Потому что может. [1] http://port70.net/%7Ensz/c/c89/c89-draft.html [2] http://port70.net/%7Ensz/c/c89/rationale/a.html#undefin... [3] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2769.pdf [4] https://isocpp.org/files/papers/P2809R3.html связанное: https://github.com/llvm/llvm-project/issues/60622 https://lobste.rs/s/wwgxzk/infinite_loops_are_ub_c https://lists.isocpp.org/std-proposals/2020/05/1322.php
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	162. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле 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ообщить модератору

	419. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (418), 20-Сен-24, 12:21
	> Лучше, если сломает. Явное лучше неявного. Явно перечисленные предупреждения лучше чем неявно, скрытые в чем-то другом.
	Ответить | Правка | Наверх | 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ообщить модератору

	390. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 13:40
	> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. И стадию внедрения бэкдора. Это не бутстрапинг. Почитай как сделано в gnu mes.
	Ответить | Правка | Наверх | Cообщить модератору

	391. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (-), 19-Сен-24, 13:46
	>> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. > И стадию внедрения бэкдора. Бремя доказательства лежит на утверждающем. Даже если он балаболка. Но пруфов от тебя, я даже не надеюсь увидеть > Это не бутстрапинг. Почитай как сделано в gnu mes. Жду определение bootstrapping, где сказано что так делать нельзя) То что ГНУтики делают как-то по другому не говорит ни о чем. Они могут хоть мозоли кушать, хоть коммуизм продвигать, это не повод за ними повторять.
	Ответить | Правка | Наверх | Cообщить модератору

	404. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 20:21
	>>> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. >> И стадию внедрения бэкдора. > Бремя доказательства лежит на утверждающем. Даже если он балаболка. > Но пруфов от тебя, я даже не надеюсь увидеть Качай бинари с интернета и запускай локально, кто тебе мешает. А как надо бутстрапить читай как уже выше сказал в gnu mes. >> Это не бутстрапинг. Почитай как сделано в gnu mes. > Жду определение bootstrapping, где сказано что так делать нельзя) > То что ГНУтики делают как-то по другому не говорит ни о чем. В основе бутстрапинга не может лежать неиследованный бинарь. > Они могут хоть мозоли кушать, хоть коммуизм продвигать, это не повод за > ними повторять. А, ну понятно с тобой все.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

	438. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (449), 21-Сен-24, 20:55
	Так используй языковой сервер и статические анализаторы, на дворе 21 век все-таки.
	Ответить | Правка | Наверх | 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++ механизмы безопасной работы с ..."	+4 +/–
	Сообщение от Аноним (123), 17-Сен-24, 17:14
	Таким как ты не угодишь. Не тащат в С++ фичи Раста - плохо. Тащат - тоже плохо.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	382. Скрыто модератором	+/–
	Сообщение от Аноним (382), 19-Сен-24, 11:59
	> Вы хотели чекер борова Нет, мы хотели чтобы перестали писать на дыряшке/плюсах, и писали на расте. > Но внезапно это оказывается - "воровать хорошие идеи". поэтому никакого противоречия. > И он еще что-то говорит про лицемерие. Именно. Это именно лицемерие. Когда годами вы говорили "ненужОн нам ваш боров, нам и так нормально!", а потом такие "хотя... подождите!"
	Ответить | Правка | Наверх | Cообщить модератору

	427. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (295), 20-Сен-24, 14:24
	> Вы хотели чекер борова - вам дают чекер борова в C++. Но внезапно это оказывается - "воровать хорошие идеи" Термин "воровать" человек применил в сердцах, от раздражения на вашу флюгерность. Да воруйте (или как хотите называйте) на здоровье! Бог в помощь! Вот только сначала долгое время кричать, что эти идеи "плохие", а потом их "воровать", соглашаясь, что они "хорошие" - вот это верх лицемерия и переобувания. Теперь объясни, когда вы были правы - тогда или сейчас, каким вашим словам верить? П - Последовательность. П.С. Можешь не отвечать, после такой последовательности в убеждениях Ваше мнение (не) ценно для нас.
	Ответить | Правка | К родителю #326 | Наверх | Cообщить модератору

	439. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (449), 21-Сен-24, 21:03
	А кто кричал, что идеи плохие? Воображаемые растохейтеры в твоей голове? Идеи хорошие, но сам Rust недостаточно хорош для перехода на него. Что тут непонятного и непоследовательного в этой позиции? P.S. Можешь не отвечать, все равно фанатики Rust ничего нового не напишут кроме своих стандартных агиток.
	Ответить | Правка | Наверх | 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++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Вы забыли заполнить поле 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ообщить модератору

	386. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 19-Сен-24, 12:38
	> Что? У вас какое-то своё собственное понимание данного термина. Алгебраические типы данных, > это например > type 'a option = >   | None >   | Some of 'a Да, каюсь - не посмотрел значение термина сначала. Теперь выяснил. И всё оказалось ещё большей чушью, чем я думал. Как говорится - поздравляю. Вы заново изобрели те же классы С++. Осталось выяснить - зачем? Только не надо мне отвечать - это был риторический вопрос, я прекрасно понимаю - зачем. Вам нужно пропихнуть ваше "поделие" всеми правдами и неправдами - вам за это платят. Или нет. Но тогда всё ещё хуже.    > Наконец-то мы договорились. А я хоть где-то утверждал, что реализовал полную спецификацию xml? Зачем мне бы это делать? У меня стояла узкая задача: организовать обработку книг в форматах fb2 и epub. Я её решил. Понадобится написать например парсер html страниц - буду решать эту задачу. И напомню, что изначально речь шла о том, что в С++ нельзя нормально работать со строками и текстом. Я вам наглядно показал, что это не так. Т.е. одно из "преимуществ" Rust - фикция. И все остальные - тоже. Потому что если разобраться, то всё уже давно есть (только не начинайте по тридцать третьему кругу заводить шарманку про работу с указателями, массивы и прочее - надоело). > Мне всё равно непонятно, зачем нужны такие костыли Какие костыли? Покажите мне хоть одну нормальную библиотеку для работы с xml на С++. Да и не нужна она в данном случае - потому что задача узкая и весьма специфическая. Тащить ради этого очередную зависимость, не пойми кем и как реализованную, или бодаться с корпорациями из-за лицензий? Зачем? Тем более, что там по итогу +/- пара сотен строчек кода. При этом я точно знаю, как это работает, и в любой момент могу что-либо откорректировать или улучшить, если возникнет такая необходимость. > Стек тоже хранится в оперативной памяти. Да что вы говорите. Правда-правда?)) Значит, аппаратный стек уже не существует? Ну ладно... >[оверквотинг удален] > различаются. > 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 их кидает. Ну и на кой изобретать вот это вот всё, когда достаточно банального switch? И, напомню, речь про С++ вообще-то. По крайней мере в контексте новости. pid_t t = fork(); switch(t) {   case -1:   {     std::cout << "Oh, shit!" << std::endl;     break;   }   case 0:   {     std::cout << "WTF are you doing? It's a child process already" << std::endl;     break;   }   default:   {     std::cout << "Dancing: " << t << std::endl;     break;   } } > Хорошо, с парсером разобрались, что такое алгебраические типы данных я вам объяснил, > что ещё вы понимаете не так? Наверняка есть ещё немало вещей, которые я не знаю или не понимаю. Вопрос то в другом - в том, что вы всё равно пишете чушь. И знаете почему? Потому что нормальные люди, когда создают некое новое техническое изделие, делают примерно такое описание: "ЯП Rust... Компилятор выполняет проверки... (перечисление, чего там он делает)". Всё, на этом точка. Допустимы также комментарии вида: "Я попробовал Rust, и увидел что он на мой взгляд лучше подходит для <перечисление задач>, потому что...". Когда же нестандартизированный ЯП пропихивают в ядро ОС, широко используемой по всему миру, а везде, где только можно, набегает толпа крикунов с лозунгами: "Ваш ЯП - говно, Rust лучший!",- это может означать только одно: в игру вступили маркетологи. Маркетологи всегда работают в чьих-то корыстных интересах. Корыстные интересы всегда направлены против общества. Т.е. в том числе против вас и меня. Даже если сами вы этого не понимаете и участвуете в пропихивании чужих корыстных интересов. Дальше - обсуждать нечего. Rust может быть как угодно прекрасен (что в реальности, мягко говоря, не так), но пока за ним стоят барыги - нет, нет и нет.
	Ответить | Правка | Наверх | Cообщить модератору

	389. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 19-Сен-24, 13:15
	> Да, каюсь - не посмотрел значение термина сначала. Теперь выяснил. И не в первый раз вы с умным видом рассуждаете про вещи, о которых почти ничего не знаете. > И всё оказалось ещё большей чушью, чем я думал. Как говорится - поздравляю. Спасибо за поздравление) Через сколько комментов будет очередное "я не почитал что оно значит"? > Вы заново изобрели те же классы С++. Осталось выяснить - зачем? ADT впервые были представленный в языке Hope аж в 1970 году. До изобретения СИшки было еще два года, до появления плюсов - больше десятка лет... > Только не надо мне отвечать - это был риторический вопрос, я прекрасно понимаю - зачем. Вам нужно пропихнуть ваше "поделие" всеми правдами и неправдами - вам за это платят. Или нет. Но тогда всё ещё хуже. Конечно это все заговор! И ничего, что они же применялись в Миранде и Хаскеле. А ведь есть еще обобщенные АТД, которые появлись немного позже. Но судя по вашим познаниям, про такие слова как OCaml, Agda или Idris вы даже не слышали. > Наверняка есть ещё немало вещей, которые я не знаю или не понимаю. О, ну хоть какая-то здравая мысль. > Вопрос то в другом - в том, что вы всё равно пишете чушь. А нет, я ошибся(( > И знаете почему? Потому что нормальные люди, когда создают некое новое техническое изделие, делают примерно такое описание: "ЯП Rust... Компилятор выполняет проверки... (перечисление, чего там он делает)". Всё, на этом точка. Странно. Они обычно пишут "UB это самая ценная вещь! она позволяет коду выдавать разыњй результат на разных компиляторах!!" > Допустимы также комментарии вида: "Я попробовал Rust, и увидел что он на мой взгляд лучше подходит для <перечисление задач>, потому что...". Угу, именно это пишется в почти каждой новости про раст: "Позволяет решать часть проблем с памятью". > Когда же нестандартизированный ЯП пропихивают в ядро ОС, широко используемой по всему миру, Имеют право. Про стандартизацию.. сишка была стандартизована спустя 17 лет после создания K&R C. Интересно, были ли тогда подобные зануды, которые ныли "как можно UNIX писать на новом нестандартизированном ЯП!" ? Надо будет - стандартизируют. Но желатьельно чтобы стандарт не был как в дыряшке "мы тут всем коммитетом не смогли за 3 года решить как складывать 2 инта.. так что пусть будет UB". > а везде, где только можно, набегает толпа крикунов с лозунгами: "Ваш ЯП - говно, Rust лучший!",- это может означать только одно: в игру вступили маркетологи. Неправда) Мы просто говорим - "Ваш ЯП - овно". А когда нас спрашивают "критикуя предлагай", от только тогда мы предлагаем. > Маркетологи всегда работают в чьих-то корыстных интересах. Дааа, заговоры! заговоры везде!! Та толпа которые в каждой теме оправдывает убогие языки "ну вышли за границы массива, это просто неправильный программист был!" это тоже маркетологи или просто местные сумасшедшие? > Корыстные интересы всегда направлены против общества. Т.е. в том числе против вас и меня. Даже если сами вы этого не понимаете и участвуете в пропихивании чужих корыстных интересов. А если я сам пишу на Расте и "пропихивание" обеспечивает мне большее число вакансий? Может это мои корыстные интересы. > Дальше - обсуждать нечего. Конечно нечего - ваша компетентность на уровне "что-то-где-то слышал, но не понял". Насколько я вижу, вы самоучка без университетского мат. образования? > Rust может быть как угодно прекрасен (что в реальности, мягко говоря, не так), но пока за ним стоят барыги - нет, нет и нет. Посмотрите кто в коммитете плюсов или си и заканчивайте пороть чушь. isocpp.org/std/the-committee Microsoft, Edison Design, Google - это те же самые "барыги". Так что выкидывайте с++ на помойку и пользуйтесь православным ДРАКОНон или КуМиром.
	Ответить | Правка | Наверх | Cообщить модератору

	393. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 19-Сен-24, 14:07
	> И не в первый раз вы с умным видом рассуждаете про вещи, > о которых почти ничего не знаете. Да-да, я ничего не знаю, конечно)) Но, проблема, повторюсь не в моём знании или незнании, а в том, что всё, что вы пишите про преимущества Rust - маркетинговая чушь. > Спасибо за поздравление) > Через сколько комментов будет очередное "я не почитал что оно значит"? Да ни через сколько - мне делами заниматься нужно, а не проплаченные комментарии по тридцать третьему разу разбирать. Так что в данном случае - этот последний, можете даже не трудиться отвечать. > ADT впервые были представленный в языке Hope аж в 1970 году. > До изобретения СИшки было еще два года, до появления плюсов - больше > десятка лет... И что?)) > Конечно это все заговор! Где заговор? Обычные коммерческие интересы и попытка устранить/подмять под себя конкурента. > И ничего, что они же применялись в Миранде и Хаскеле. И что?)) > А ведь есть еще обобщенные АТД, которые появлись немного позже. > Но судя по вашим познаниям, про такие слова как OCaml, Agda или > Idris вы даже не слышали. А оно точно надо?)) > О, ну хоть какая-то здравая мысль. Да, у меня тоже бывают озарения)) > А нет, я ошибся(( И даже не подозреваете - в чём ваша ошибка на самом деле. > Странно. Они обычно пишут "UB это самая ценная вещь! она позволяет коду > выдавать разыњй результат на разных компиляторах!!" Ну т.е. вы лишний раз только подтверждаете мои слова про крикунов и маркетологов. > Угу, именно это пишется в почти каждой новости про раст: "Позволяет решать > часть проблем с памятью". И под каждой новостью вам пишут, что - ну и пускай себе. Проблема не в этом, а в вас. В том числе лично в вас. > Имеют право. Нет, не имеют. Но видимо придётся вам это объяснять другими методами, а не словами. Поскольку по-хорошему вы, и подобные вам, не хотите. И я сейчас не про ЯП совсем. > Про стандартизацию.. сишка была стандартизована спустя 17 лет после создания K&R C. И что? > Интересно, были ли тогда подобные зануды, которые ныли "как можно UNIX писать > на новом нестандартизированном ЯП!" ? Тогда ситуация совсем другая была - вычислительная техника в современном виде только-только появлялась. Про стандартизацию никто и не вспоминал ещё. > Надо будет - стандартизируют. Вот тогда и поговорим. > Но желатьельно чтобы стандарт не был как в дыряшке "мы тут всем > коммитетом не смогли за 3 года решить как складывать 2 инта.. > так что пусть будет UB". И снова наброс. Т.е. снова вы расписались в своей ангажированности. > Неправда) Мы просто говорим - "Ваш ЯП - овно". > А когда нас спрашивают "критикуя предлагай", от только тогда мы предлагаем. А вам говорят: ваши предложения - чушь. И опровергнуть это вы не можете. > Дааа, заговоры! заговоры везде!! Дааа, нужно облить оппонента грязью, объявить психом, и т.д. и т.п. Лишь бы пропихнуть своё. А какое оно по качеству - да плевать. "Умри ты сегодня, а я - завтра". > Та толпа которые в каждой теме оправдывает убогие языки "ну вышли за > границы массива, это просто неправильный программист был!" это тоже маркетологи или > просто местные сумасшедшие? Кто тут и чего оправдывает? Вам нормальным языком говорят: про проблемы мы в курсе, только вот решать их будем без ваших "ценных" предложений, поскольку на поверку все они - рекламная глупость. > А если я сам пишу на Расте и "пропихивание" обеспечивает мне большее > число вакансий? Вам - да. А обществу от этого польза будет? Если нет, то придётся вам чем-нибудь другим заняться. Не можете, потому что нет денег на переобучение? Ну поздравляю, вы на себе почувствовали, что такое капитализм, и как он работает. Может быть даже осознаете, в чём ваша проблема на самом деле заключается. > Может это мои корыстные интересы. Не может, а точно. Только на вас свет клином не сошёлся. Вы для общества важны, но не более важны, чем любой другой человек. > Конечно нечего - ваша компетентность на уровне "что-то-где-то слышал, но не понял". Ну т.е. в очередной раз будем обсуждать мою компетентность. Потому что по существу ответить нечего. > Насколько я вижу, вы самоучка без университетского мат. образования? Самоучка - да. В плане программирования. Без университетского образования - да. Поскольку заканчивал таки ГМА им. адм. Макарова (которая теперь по иронии - университет, но это совсем другая история). Так что с математическим образованием у меня всё в порядке. А ещё с техническим, да и с естественно-научным - тоже (но это уже больше заслуга школы, а также самообразование). > Посмотрите кто в коммитете плюсов или си и заканчивайте пороть чушь. > isocpp.org/std/the-committee > Microsoft, Edison Design, Google - это те же самые "барыги". > Так что выкидывайте с++ на помойку и пользуйтесь православным ДРАКОНон или КуМиром. Весь вопрос в том, что в комитете С++ - они конкуренты, поэтому в итоге мы получаем пусть шаткий, но баланс. Плюс к тому есть независимая реализация компилятора (что на самом деле важнее). А в Rust - они тоже конкуренты. Будут, чуть по позже. Когда удастся подмять Linux под себя. Впрочем, есть неплохой шанс, что они таки поссорятся на этой теме. Но вряд ли успеют. Потому что в самом ближайшем будущем никаких корпораций вообще не останется. По одной из двух причин: будет революция или все сдохнут. Выбирайте, что вам больше нравится.
	Ответить | Правка | К родителю #389 | Наверх | Cообщить модератору

	394. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 19-Сен-24, 15:47
	> Да-да, я ничего не знаю, конечно)) Подмена понятий это не очень красивая манипуляция. Приравнивание "почти ничего" и "ничего". > вы пишите про преимущества Rust - маркетинговая чушь. Бездоказательное утверждение. > а не проплаченные комментарии по тридцать третьему разу разбирать. Обвинить в пропалченности - всегда легко. Особенно бездоказаетльно. Но считать всех, кто с вами не согласен, ботами или проплаченными это довольно сильно. ВОзможно сильно глупо. >> ADT впервые были представленный >> И ничего, что они же применялись в Миранде и Хаскеле. > И что?)) А ничего. Просто эти подходы очень старые. Их преимущества и недостатки известны. Оно позволяет делать классные вещи для сложных систем. > А оно точно надо?)) Конечно, оно позволяет совершать меньше ошибок. >> Имеют право. > Нет, не имеют. Но видимо придётся вам это объяснять другими методами, а не словами. Поскольку по-хорошему вы, и подобные вам, не хотите. И я сейчас не про ЯП совсем. Т.е автор не может со своим проектом делать то, что пожелает? Сменить лицензию. Удалить весь код и тд? Думаю, вам бы не понравилось если бы я начал менять ваш проект без спросу. Линус и разработчики решили что в ядре будет Раст - это их право. Ваше - не пользоваться или форкать. >> Про стандартизацию.. сишка была стандартизована спустя 17 лет после создания K&R C. > И что? Это то, что даже на нестандартизованном языке можно писать серьезные системы. >> Но желатьельно чтобы стандарт не был как в дыряшке "мы тут всем коммитетом не смогли за 3 года решить как складывать 2 инта.. так что пусть будет UB". > И снова наброс. Т.е. снова вы расписались в своей ангажированности. Наброс? Могу процитировать "так называемый стандарт" Пункт 6.5.6 Additive operators подпункт 8 the evaluation shall not produce an overflow; otherwise, the behavior is undefined > А вам говорят: ваши предложения - чушь. И опровергнуть это вы не можете. А вам говорят: ваши предложения - чушь. И опровергнуть это вы не можете. Стрелочка, она в обе стороны может поворачиваться. > Дааа, нужно облить оппонента грязью, объявить психом, и т.д. и т.п. Никогда такого не делал. У меня математическое образование. И принимать что-то на веру я не привык. Если бы вы сказали "вот доказательства", то разговор был бы другой. А если кричать "волк! волк!" то на третий раз уже никто всерьез воспринимать не будет. > А какое оно по качеству - да плевать. Лучше чем то, что было. Этого достаточно. > "Умри ты сегодня, а я - завтра". Так все умрем когда-то. Может у меня даже больше шансов чем у вас тк я моложе. Я думаю мы понимаем о чем речь. > Кто тут и чего оправдывает? Вам нормальным языком говорят: про проблемы мы в курсе, только вот решать их будем без ваших "ценных" предложений, Кто такое говорит? Как раз разработчики ядра другого мнения. Но да, они разберутся без ваших ценных предложений и без моих тоже. Т.к они разработчики, а не я или вы. > Вам - да. А обществу от этого польза будет? Если нет, то придётся вам чем-нибудь другим заняться. Не можете, потому что нет денег на переобучение? Ну поздравляю, вы на себе почувствовали, что такое капитализм, и как он работает. Может быть даже осознаете, в чём ваша проблема на самом деле заключается. Общество получит: 1. более надежный код, которые не разваливается от 28 бекспейсов 2. код не нужно будет годами чинить, находя все новые и новые баги То что мне придется переучиваться.. Это назывется не капитализм, а прогресс. Без него мы бы до сих пор с каменными топорами ходили, и то если бы с дерева слезли. > Самоучка - да. В плане программирования. Без университетского образования - да. Поскольку заканчивал таки ГМА им. адм. Макарова (которая теперь по иронии - университет, но это совсем другая история). Так что с математическим образованием у меня всё в порядке. А ещё с техническим, да и с естественно-научным - тоже (но это уже больше заслуга школы, а также самообразование). Я спросил это просто для понимания, слушали ли вы лекции по мат.логике, теории множеств и тд > Весь вопрос в том, что в комитете С++ - они конкуренты, поэтому в итоге мы получаем пусть шаткий, но баланс. Плюс к тому есть независимая реализация компилятора (что на самом деле важнее). А в Rust - они тоже конкуренты. Будут, чуть по позже. Почему будут позже? Они вполне могут стараться протолкнуть свои наработки в язык. > Когда удастся подмять Linux под себя. А... а зачем? Просто открываем linuxfoundation.org/about/members ... А там Майкрософт, Оракл и фейсбук в платиновых спонсорах. Смотрим на директоров www.linuxfoundation.org/about/leadership Да что ж такое! Опять эти корпы. Ладно, сообщество же пишет код.. 80% вклада - это программисты на зарплате корпов. Они УЖЕ его подмяли, хотя чеснее сказать "они его создали". Пример с системмд и вейландом это только подтвердят мое утверждение. > Впрочем, есть неплохой шанс, что они таки поссорятся на этой теме. Но вряд ли успеют. Потому что в самом ближайшем будущем никаких корпораций вообще не останется. По одной из двух причин: будет революция или все сдохнут. Выбирайте, что вам больше нравится. Ну революция уже была, лет 100 назад. И закончилось все голодом, мировыми войнами, геноцидами и прочим. Спасибо не надо.
	Ответить | Правка | К родителю #393 | Наверх | Cообщить модератору

	396. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 18:17
	>> До изобретения СИшки было еще два года, до появления плюсов - больше >> десятка лет... >И что?)) А то, что нормальные языки появились давным давно, но были затмены говнокодом. И если си ещё мог с ними соревноваться, так как он ровесник некоторых из них, то вот уже c++ или python - появились после них, и уже на момент своего релиза отставали по фичам. Про голанг и говорить не приходится >Вам нормальным языком говорят: про проблемы мы в курсе А точно в курсе? Вы давненько уже опубликовали свою программу, кто-то ваш код читал и про парсер вам писал? Другие части ревьювил? Увы, но далеко не у каждого сишника/плюсовика есть человек, который объяснит ему что и почему он сделал неправильно. >Самоучка - да. В плане программирования. Без университетского образования - да Учитывая то, какие в некоторых ВУЗ-ах программы, то диплом тоже ничего не гарантирует. Если это не МГУ какое-нибудь.
	Ответить | Правка | К родителю #393 | Наверх | Cообщить модератору

	400. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Fyjy (-), 19-Сен-24, 19:06
	> А то, что нормальные языки появились давным давно, но были затмены говнокодом. О да) СИшка это ПХП из 70х, чтобы любой б-ло кодер мог забацать какой-то код, и если ему удача повернется лицом, даже переносимый. Можно вспомнить как разрабатывалась АДА. Сначала они 2 года и 5 итераций собирали требования. Потом они устроили конкурс на разработку нового языка и 5 лет он был написан. Потом они запретили выпускать компиляторы, которые не прошли пакет тестов (больше тысячи). Хотя бы один тест провалился - всё, ты идешь лесом. Если вспомнить как рождался СИ и его стандарт (на который тая неистово фапают фанатики), то это десятки не совместимых друг с другом компиляторов, куча противоречий в стиле "ХЗ чо тут делать, компилятор сам разберется" и как вишенка на торте и овна - стандарт не обязателен к выполнению. Отрываешь C compiler support en.cppreference.com/w/c/compiler_support смотришь на красные пятна неподдерживаемых фич и думаешь, а почему это овно вообще называется "компилятор С"? И с плюсами история почти такая же. С теми же последствиями. en.cppreference.com/w/cpp/compiler_support Но, история не имеет сослагательного наклонения, и быд-о код победил. Язык для которого уровень квалификации пограммиста нужен был "бибизяна умеет жать на клавиши" распространился в очень важные проекты.
	Ответить | Правка | К родителю #396 | Наверх | Cообщить модератору

	408. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 19-Сен-24, 21:24
	> А то, что нормальные языки появились давным давно, но были затмены говнокодом. > И если си ещё мог с ними соревноваться, так как он > ровесник некоторых из них, то вот уже c++ или python - > появились после них, и уже на момент своего релиза отставали по > фичам. Про голанг и говорить не приходится Ну т.е. опять безосновательный наброс. Какие "фичи", вы о чём вообще? У вас на С++ стандартная библиотека такого размера, что её ни один программист целиком не знает (да и не нужно это - нормальные люди перед реализацией интересуются наличием необходимых инструментов). Плюсом к этому в С++ вы вполне можете использовать примерно 99% кода из С напрямую. Если не хватает и этого - вам сделали ассемблерные вставки: делайте, что хотите.   > А точно в курсе? Вы давненько уже опубликовали свою программу, кто-то ваш > код читал и про парсер вам писал? Другие части ревьювил? Увы, > но далеко не у каждого сишника/плюсовика есть человек, который объяснит ему > что и почему он сделал неправильно. Прикрутите фонтан самомнения, иначе мне придётся вам в грубой форме пояснить, куда вам следует сходить. А мне бы этого не хотелось - здесь детей много. > Учитывая то, какие в некоторых ВУЗ-ах программы, то диплом тоже ничего не > гарантирует. Если это не МГУ какое-нибудь. Хы)) Я таких выпускников МГУ видал, что их на пушечный выстрел вообще ни к чему подпускать нельзя. Это я к том, что ВУЗ - да, не показатель. А вот профессия - по обстоятельствам. В моей (теперь уже бывшей), если вы не будете нормально применять знания, то всё закончится или вашей смертью, или тюрьмой. Я пока жив и даже на свободе, так что, видимо, образование у меня неплохое))
	Ответить | Правка | К родителю #396 | Наверх | Cообщить модератору

	435. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 21-Сен-24, 17:41
	>Какие "фичи", вы о чём вообще? Например, алгебраические типы данных. Никаким размером стандартной библиотеки их отстутствие не компенсировать >Плюсом к этому в С++ вы вполне можете использовать примерно 99% кода из С напрямую В какой-то момент хочется не количества, а качества >Прикрутите фонтан самомнения, иначе мне придётся вам в грубой форме пояснить, куда вам следует сходить. Самомнение здесь только у вас, раз на обоснованную критику вы готовы посылать в грубой форме
	Ответить | Правка | К родителю #408 | Наверх | Cообщить модератору

	395. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 17:56
	>Да, каюсь - не посмотрел значение термина сначала. Теперь выяснил. И всё оказалось ещё большей чушью, чем я думал Хорошо, что вы не закостенелив в своём незнании >Вы заново изобрели те же классы С++ Алгебраические типы данных решают схожую, но всё же отличающуюся задачу. Решение через классы будет гораздо многословнее, но проблема даже не в многословности. Проблема в том, чтобы убедить плюсовиков преодолеть "парадокс блаба"(да, по этому поводу есть хорошая статья). >Ну и на кой изобретать вот это вот всё, когда достаточно банального switch? И, напомню, речь про С++ вообще-то. Всё просто и понятно. Во-первых, данное решение проверяется компилятором. Если я из вашего примера удалю case -1, то код по прежнему будет компилироваться, и никто мне никакую ошибку не выдаст. При работе со сложными форматами крайне важно понимать, что обработал все варианты. Во-вторых, добавив к этому монады получаем крайне высокую выразительность, в то время как ваш код превратится в ад вложений. >А я хоть где-то утверждал, что реализовал полную спецификацию xml? У вас файл называется XMLParser. >Да и не нужна она в данном случае - потому что задача узкая и весьма специфическая Вот эта вот часть мне в плюсовиках не нравится: они вначале пишут непонятно что, а потом, после того, как им расскажут, почему их решение плохое, они начинают оправдываться. >Понадобится написать например парсер html страниц - буду решать эту задачу HTML это типичный кошмар, изобретённый сишниками/плюсовиками. Огроменная спецификация, огроменное количество подводных камней. Могли бы сделать XHTML, но сишников/плюсовиков тянет к уродству. Как следствие, для того, чтобы реализовать правильный парсер html - нужно приложить ещё больше усилий >Я вам наглядно показал, что это не так У вас как таковой работы и нет. Вы используете поиск по строке и берёте подстроки. Вы не делаете каких-то сложных преобразований >Покажите мне хоть одну нормальную библиотеку для работы с xml на С++ Я на плюсах не пишу, по этому ничего сказать не могу. Но вы же утверждаете, что работать со строками легко. И потом, xml это хоть и сложный формат, но реализовать парсер с нуля должно быть по силам даже одному человеку. >Да и не нужна она в данном случае - потому что задача узкая и весьма специфическая Всегда, когда вы работаете с какими-то форматами, вы должны реализовывать работу по спецификации. В данном случае, даже если бы вы писали просто Proof of Concept, то это не дало бы вам выигрыша по времени, поскольку нормальный парсер пишется совершенно иначе. Ваш код в любом случае нужно будет просто выкинуть. https://dev.realworldocaml.org/parsing-with-ocamllex-and-men... >Тащить ради этого очередную зависимость, не пойми кем и как реализованную Вы не доверяете авторам библиотек на плюсах? Я без сомнений использую чужой код в Ocaml >Тем более, что там по итогу +/- пара сотен строчек кода XML это не JSON, строк там понадобится куда больше. >Значит, аппаратный стек уже не существует? И что по вашему хранится в этом аппаратном стеке? Учтите, что вам туда надо будет засунуть буквально всё: стек каждого процесса, стек каждого потока. Надеюсь, вы понимаете, что держать запущенными на одном устройстве пусть две тысячи одновременных стеков - это не что-то выдающееся? >а везде, где только можно, набегает толпа крикунов с лозунгами: "Ваш ЯП - говно, Rust лучший!",- это может означать только одно: в игру вступили маркетологи Если вы не заметили, то конкретно я говорю про Ocaml. Может быть, я когда-нибудь напишу что-то на PureScript или Gluon, но на данный момент я говорю про Ocaml, а rust - так, по остаточному принципу >Ваш ЯП - говно, Rust лучший! Я устал от говнокода. Когда очередная программа падает с сегфолтом или работает неправильно, в 2024 году, у меня и возникает желаение рассказывать, какое уродство си и c++. Когда я понимаю, как легко создать баг на си/плюсах, у меня отпадает малейшее желание писать хоть самый маленький патч для этих программ.
	Ответить | Правка | Наверх | Cообщить модератору

	407. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 19-Сен-24, 21:10
	> Хорошо, что вы не закостенелив в своём незнании Чего-то не знать не стыдно. Стыдно не стремиться расширять свой кругозор. > Алгебраические типы данных решают схожую, но всё же отличающуюся задачу. Решение через > классы будет гораздо многословнее, но проблема даже не в многословности. Проблема > в том, чтобы убедить плюсовиков преодолеть "парадокс блаба"(да, по этому поводу > есть хорошая статья). А зачем собственно? Не устраивает - пишите на том языке, на котором вам удобно. Зачем плюсовиков в чём-то убеждать? Они ж по большей части в геймдеве заняты. А эта область - далеко не весь IT сектор, и даже не самый важный (если не сказать больше - на 99,9% ненужный). Хотя язык сам по себе - очень даже неплох. И реализации есть нормальные. И лично мне например непонятно, почему тот же Торвальдс не хочет его разрешать использовать в ядре. Но это моё личное мнение, я его никому не навязываю. > Всё просто и понятно. Во-первых, данное решение проверяется компилятором. Если я из > вашего примера удалю case -1, то код по прежнему будет компилироваться, > и никто мне никакую ошибку не выдаст. При работе со сложными > форматами крайне важно понимать, что обработал все варианты. Во-вторых, добавив к > этому монады получаем крайне высокую выразительность, в то время как ваш > код превратится в ад вложений. Есть и противоположные варианты - когда вам по большому счёту всё равно, стартовал процесс или нет, главное - сохранить работоспособность программы и не тратить ресурсы на обработку ошибок. Их и потом собрать можно, по результатам работы программы. Ну и зачем мне в таком разе компилятор, который будет нудеть про необработанные варианты? Если же вы не обработали ошибку по незнанию, то тут уж извините - это сугубо проблема вашей квалификации. Вы на то и программист, чтобы такими вещами заниматься, и учитывать всё, что нужно. > У вас файл называется XMLParser. И что? Как он ещё должен называться? Если по факту - это и есть xml парсер. Потому как что в fb2, что в epub используются урезанные специфические xml форматы. > Вот эта вот часть мне в плюсовиках не нравится: они вначале пишут > непонятно что, а потом, после того, как им расскажут, почему их > решение плохое, они начинают оправдываться. Да при чём тут оправдания, если вы не разобравшись, пишете чушь? Ещё раз - в данном случае есть форматы fb2 и epub, в них используется вполне определённый набор xml свойств, которые к основной части формата имеют достаточно косвенное отношение. Найдите спецификацию того же fb2 на github - поймёте, о чём я говорю. > HTML это типичный кошмар, изобретённый сишниками/плюсовиками. Огроменная спецификация, > огроменное количество подводных камней. Могли бы сделать XHTML, но сишников/плюсовиков > тянет к уродству. Как следствие, для того, чтобы реализовать правильный парсер > html - нужно приложить ещё больше усилий Это только ваше мнение)) > У вас как таковой работы и нет. Вы используете поиск по строке > и берёте подстроки. Вы не делаете каких-то сложных преобразований А зачем? Задача данного парсера - достать из файла точно то, что от него попросили. Например - имя автора. Всё остальное обрабатывается уровнем выше. > Я на плюсах не пишу, по этому ничего сказать не могу. Но > вы же утверждаете, что работать со строками легко. И потом, xml > это хоть и сложный формат, но реализовать парсер с нуля должно > быть по силам даже одному человеку. Да не вопрос - я бы даже взялся. Если мне за это заплатят. И не потому что я такой жадный, а потому, что мне нужно что-то есть, при этом лично мне xml не упёрся ни разу. Понадобилось обрабатывать его частный вариант - я сделал. Если понадобится полный - тоже сделаю. Пока что он мне не нужен. > Всегда, когда вы работаете с какими-то форматами, вы должны реализовывать работу по > спецификации. В данном случае, даже если бы вы писали просто Proof > of Concept, то это не дало бы вам выигрыша по времени, > поскольку нормальный парсер пишется совершенно иначе. Ваш код в любом случае > нужно будет просто выкинуть. https://dev.realworldocaml.org/parsing-with-ocamllex-and-men... Так я и сделал по спецификации. https://github.com/gribuser/fb2 > Вы не доверяете авторам библиотек на плюсах? Я без сомнений использую чужой > код в Ocaml Я в принципе стараюсь использовать как можно меньше зависимостей. И дело даже не в том, что я кому-то не доверяю. Просто вот вам наглядный пример с libarchive - баг с rar архивами висит, исправлений нет. Потому что сопровождающим видимо не до того. Или нет таких. Сам я тоже этим возможности заниматься не имею. Да и желания тоже - как и писал выше, это проприетарь (имеется ввиду rar). Разбираться с ней - себе дороже. А альтернатив для libarchive пока что нет особо. > XML это не JSON, строк там понадобится куда больше. Ну понадобится и понадобится - если нужно будет, сделаю. > И что по вашему хранится в этом аппаратном стеке? Учтите, что вам > туда надо будет засунуть буквально всё: стек каждого процесса, стек каждого > потока. Надеюсь, вы понимаете, что держать запущенными на одном устройстве пусть > две тысячи одновременных стеков - это не что-то выдающееся? Мне не нужно в аппаратный стек чего-то засовывать. Всё происходит автоматом при исполнении программы. Дело в том, что определённые типы данных, вроде того же int такие, какие есть, потому что они напрямую завязаны на аппаратную реализацию. За счёт этого они работают очень быстро, но при этом имеют ограничения по размеру в битах. А значит и ограничения по максимальным значениям. Тут "или-или": или вы имеете данные произвольного размера, но тогда обрабатывает их как массивы, что относительно медленно (в стек их засовывать неразумно, а значит будете дёргать их из памяти), или работаете с данными фиксированного размера, но тогда вам нужно учитывать соответствующие ограничения. > Если вы не заметили, то конкретно я говорю про Ocaml. Может быть, > я когда-нибудь напишу что-то на PureScript или Gluon, но на данный > момент я говорю про Ocaml, а rust - так, по остаточному > принципу Ну и зачем вы мне тогда всё это пишете? Вам не всё ли равно, что я думаю о Rust? Да и я против других языков ничего не имею. Уже устал повторять - пишите вы на чём хотите, это ваше дело. Меня в данной ситуации напрягает именно само пропихивание языка и методы этого пропихивания. Потому что технически оно явно неоправданно. А значит - кто-то пытается на этом поиметь личную выгоду. За счёт общественного достояния, каковым ядро Линукс по сути и является. Я, если вы не заметили, вообще ничего не пишу, когда тут идут новости про ОС на Rust: хотят люди - пусть делают, это их время и им решать, на что его тратить. > Я устал от говнокода. Когда очередная программа падает с сегфолтом или работает > неправильно, в 2024 году, у меня и возникает желаение рассказывать, какое > уродство си и c++. Когда я понимаю, как легко создать баг > на си/плюсах, у меня отпадает малейшее желание писать хоть самый маленький > патч для этих программ. Ну так и не пишите, и не пользуйтесь "говнокодом" - вас насильно никто не заставляет.
	Ответить | Правка | К родителю #395 | Наверх | Cообщить модератору

	409. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 19-Сен-24, 23:59
	>Зачем плюсовиков в чём-то убеждать? Они ж по большей части в геймдеве заняты Увы, но нет. Огромное количество софта написано на си/плюсах. Vim, jq, Inkscape, Firefox, NetworkManager и так далее. Это очень разные сферы, с очень разными требованиями, но все как под копирку. В последнее время немного go популяризуется, но он в основном в мелких консольных утилитах. >и не тратить ресурсы на обработку ошибок Откуда такое нежелание обрабатывать ошибки? И потом, даже если размер возвращаемый fork-ом возрастёт в несколько раз, это всё равно не получится заметить. Это буквально экономия на спичках >Потому как что в fb2, что в epub используются урезанные специфические xml форматы Вот пример, есть два атрибута, и оба - строки. https://github.com/gribuser/fb2/blob/master/FictionBookLinks... Каким образом вы гарантируете, что в эти строки случайно или умышеленно не попадёт имя атрибута как подстрока? И потом, экранироваться должен любой пользовательский ввод, иначе программа ненадёжна. Слишком велик шанс того, что в противном случае нужное значение забудут обработать. >Как он ещё должен называться? Если по факту - это и есть xml парсер Этот код имеет к парсеру отношение не больше чем grep и sed. Он не обрабатывает ни ошибки синтаксиса, ни экранирование спецсимволов в атрибутов, ни прочие вещи >Да не вопрос - я бы даже взялся. Если мне за это заплатят. Пара минут поиска, и я выяснил, что существует libxml2. >Дело в том, что определённые типы данных, вроде того же int такие, какие есть, потому что они напрямую завязаны на аппаратную реализацию. За счёт этого они работают очень быстро, но при этом имеют ограничения по размеру в битах. Почитайте, как алгебраические типы данных реализованы в rust и ocaml(подсказка: очень эффективно). Rust это вообще системный язык(с вытекающей отсюда производительностью и низкоуровневостью). >Ну так и не пишите, и не пользуйтесь Увы, но я не могу писать абсолютно весь софт для себя сам. Вот не смогу я написать, например видеоредактор для того, чтобы однократно видео обрезать.
	Ответить | Правка | К родителю #407 | Наверх | Cообщить модератору

	420. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 20-Сен-24, 12:59
	> Увы, но нет. Огромное количество софта написано на си/плюсах. Vim, jq, Inkscape, > Firefox, NetworkManager и так далее. Это очень разные сферы, с очень > разными требованиями, но все как под копирку. В последнее время немного > go популяризуется, но он в основном в мелких консольных утилитах. Спасибо, но вот go - точно не надо. > Откуда такое нежелание обрабатывать ошибки? Дело не в нежелании, а в возможностях. Вы уверены, что на каком-нибудь микроконтроллере у вас будет достаточно ресурсов? А системы реального времени? Где критически важно время обработки того или иного сигнала, а ошибки - можно и потом обработать. Например проверив - отработал ли процесс. > И потом, даже если размер возвращаемый fork-ом > возрастёт в несколько раз, это всё равно не получится заметить. Это > буквально экономия на спичках Ну во-первых, на fork свет клином не сошёлся. Во-вторых, опять же там, где достаточно банального int размером 16-32 бита, вы предлагаете запихнуть целый класс. Зачем? Более того, если уж так зачесалось - то на С++ делается это элементарно. Можно даже класс не создавать, обойтись локальной struct. Эффект будет тем же самым. Так что снова мимо. В общем - не нужен Rust, не нужен. Смиритесь уже)) И лучше своё время потратьте на что-нибудь более полезное, чем бесполезные комментарии на форумах. > Вот пример, есть два атрибута, и оба - строки. https://github.com/gribuser/fb2/blob/master/FictionBookLinks... > Каким образом вы гарантируете, что в эти строки случайно или умышеленно > не попадёт имя атрибута как подстрока? И потом, экранироваться должен любой > пользовательский ввод, иначе программа ненадёжна. Слишком велик шанс того, что в > противном случае нужное значение забудут обработать. Смотрите код, как обрабатываются атрибуты. > Этот код имеет к парсеру отношение не больше чем grep и sed. > Он не обрабатывает ни ошибки синтаксиса, ни экранирование спецсимволов в атрибутов, > ни прочие вещи Всё он прекрасно обрабатывает)) И вопрос не в том, как файл называется, а в том, что код делает. В данном случае - ровно то, что от него требуется. Если у вас есть желание докопаться до столба - пожалуйста, но только без меня. Потому как сути дела всё это не поменяет - ваши наезды на С/С++ абсолютно безосновательны, и вызваны отнюдь не техническими особенностями того или иного ЯП. Дальше данную тему смысла обсуждать не вижу. > Пара минут поиска, и я выяснил, что существует libxml2. Ну во-первых, она на С, а не на С++. Но это не суть важно. Важно другое: как и писал выше - зачем? Пара сотен строчек кода, и я получил ровно то, что мне нужно. После чего продолжил заниматься своими делами. А не ковыряться в незнакомом API, разбираясь, как его подогнать под выполняемые программой задачи. При этом моя программа не зависит от сторонней библиотеки. Т.е. ошибки/изменения  API в ней мне абсолютно по барабану, и не придётся тащить в систему нехилый кусок лишнего кода. > Почитайте, как алгебраические типы данных реализованы в rust и ocaml(подсказка: очень эффективно). Всё равно они работают медленнее банального int. Как и написал выше - вы мне предлагаете вместо 16-32 бит использовать целый класс. Зачем? Тем более, что на этапе проектирования программы всегда ясно - будет ли значение выходить за пределы размерности того или иного типа данных. И если такая вероятность есть, то нормальный программист это будет учитывать. > Rust это вообще системный язык(с вытекающей отсюда производительностью и низкоуровневостью). Да без проблем. Дело в другом - он просто не нужен. Он возник, потому что несколько "не таких, как все" чисто по приколу решили написать свой язык. А корпорации в нём увидели способ нажиться - и понеслась. С технической точки зрения оно бесполезно от слова совсем, поскольку создаёт ненужные проблемы на ровном месте, а вот преимущества - весьма сомнительные. Rust и прочие подобные ЯП пытаются решить ровно одну проблему: падение уровня квалификации программистов. И предлагаемыми методами этого не решить. Потому что источник проблемы лежит не в ЯП, и даже не в IT в целом. Решать же проблему предлагается... встраиванием статического анализатора кода в компилятор. И зачем? Если можно просто написать нормальный статический анализатор кода для тех же С/С++? В общем лучше, как уже написал выше, смиритесь и потратьте время на что-то более полезное, чем на споры со мной.   > Увы, но я не могу писать абсолютно весь софт для себя сам. > Вот не смогу я написать, например видеоредактор для того, чтобы однократно > видео обрезать. Не нужно ничего писать. Просто бросьте ф...ней страдать, и внезапно всё наладится. У вас проблемы есть куда как посерьёзнее, чем бессмысленные споры о ненужных ЯП - вот-вот мировая война очередная начнётся. А может даже и уже идёт.
	Ответить | Правка | К родителю #409 | Наверх | Cообщить модератору

	425. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 20-Сен-24, 13:25
	> Дело не в нежелании, а в возможностях. Вы уверены, что на каком-нибудь микроконтроллере у вас будет достаточно ресурсов? А системы реального времени? Нет конечно. Но речь идет о ядре линукс или вообще о телефонах с андроидом. Для микроконтроллеров и тем более RTOS подходы совершенно другие. > Где критически важно время обработки того или иного сигнала, а ошибки - можно и потом обработать. Например проверив - отработал ли процесс. Прям как сделали разработчики Therac-25 убившие кучу народу. Или просто перезагрузив весь контроллер, как сделали Тойотовцы, и тоже с человеческими жертвами. > В общем - не нужен Rust, не нужен. Смиритесь уже)) Вы видели мемное видео про "не нужон ваш интернет!"? Оно мне чего-то вспомнилось) > И лучше своё время потратьте на что-нибудь более полезное, чем бесполезные комментарии на форумах. Комментарии полезные. Придует такой зеленый программист, студент или даже школьник. Почитает какое дно языки прошлого столетия и возможно не будет вкладывать в них усилия. Это же просто забота о нашем будущем! > Да без проблем. Дело в другом - он просто не нужен. Он возник, потому что несколько "не таких, как все" чисто по приколу решили написать свой язык. Примерно как Страуструп расширял СИшку? И потом выкатил си++? Вы не слышали как появилась QNX? Пара студентов после базового(!!) курса "как разработать ОС" решили попробовать. И у них получилось! А еще можно взять в пример одного матюкающегося фина, который решил "буду не такой как все! запилю свое ядро". > А корпорации в нём увидели способ нажиться - и понеслась. Хм.. и как они на нем наживаются? > С технической точки зрения оно бесполезно от слова совсем, поскольку создаёт ненужные проблемы на ровном месте, а вот преимущества - весьма сомнительные. Не уверен что моих или ваших компетенций достаточно, чтобы оценить техническую точку зрения. > Rust и прочие подобные ЯП пытаются решить ровно одну проблему: падение уровня квалификации программистов. О, начинается)) "раньше програмитсы быљи огого, а сейчас... И код был оггого! Не то что сейчас" Можно просто написать в поиске этого сайта "уязвимость" и посмотреть как "качественно" писали раньше. > Решать же проблему предлагается... встраиванием статического анализатора кода в компилятор. И зачем? Если можно просто написать нормальный статический анализатор кода для тех же С/С++? Но за пол века его никто не написал. Наверное никому не нужно. > У вас проблемы есть куда как посерьёзнее, чем бессмысленные споры о ненужных ЯП - вот-вот мировая война очередная начнётся. А может даже и уже идёт. Т.е если где-то идет война, можно работу делать тяп-ляп? А может я уже на войне и мне нужен надежный ЯП, программу на котором не смогут взломать "написав" 28 бекспесов?
	Ответить | Правка | К родителю #420 | Наверх | Cообщить модератору

	430. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от ProfessorNavigator (ok), 20-Сен-24, 15:13
	Давайте так. Я вам отвечу, но при одном условии - вы честно скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку. В противном случае - общайтесь с зеркалом. Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно.
	Ответить | Правка | К родителю #425 | Наверх | Cообщить модератору

	431. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (-), 20-Сен-24, 16:46
	> Давайте так. Я вам отвечу, но при одном условии Да вы не утруждайтесь вы так. Зачем тратить время на каких-то анонимов. > - вы честно  скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку. Предложение конечно интересное, но ответу "мне не платят, я просто весело провожу время" вы наверняка не поверите. И это ваше полное право. > В противном случае - общайтесь с зеркалом. Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно. Так ответов особо и не было. Были какие-то бездоказательные утверждения про "не нужно", "маркетинг", "получают выгоду", "ничем не лучше". Которые как чайник рассела - ни опровергнуть, ни подтвердить. Причем они пихаются как аксиомы.
	Ответить | Правка | К родителю #430 | Наверх | Cообщить модератору

	433. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 20-Сен-24, 19:49
	>Я вам отвечу, но при одном условии - вы честно скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку. Рыцарь на белом коне, вы Дон Кихот. Достаточно просто почитать спецификации си/плюсов, чтобы было понятно какой это ужас. Если вы недостаточно компетентны, то пойдите, почитайте, например блог PSV-Studio, разработавший статический анализатор для данных языков. >Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно. Вы не обсуждаете, вы строите свои догадки, и блуждаете в плену иллюзий. Я вам несколько раз писал про алгебраические типы, но вы не удосужились прочитать, что это, и высказали своё неприятие. Только после того, как я привёл вам пример, вы признались в собственном незнании. Теперь вы придумали, что ADT реализуются как классы, с алокацией памяти в куче. Далее, будет идти вопрос о том, зачем нужен тип Option, когда есть null, но вы настолько застряли в "парадоксе Блаба", что отвергаете всё вам непонятное.
	Ответить | Правка | К родителю #430 | Наверх | Cообщить модератору

	432. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (175), 20-Сен-24, 19:26
	>Спасибо, но вот go - точно не надо. Уж лучше уж go, чем си/плюсы, там хоть программистов муштруют GC, и постоянными err != nil. Авось, go-шник, уставший после каждой строки писать err != nil оценит красоту того же Ocaml. >Дело не в нежелании, а в возможностях. Вы уверены, что на каком-нибудь микроконтроллере у вас будет достаточно ресурсов? С какого момента речь зашла о микроконтроллерах? Почему при программировании десктопного/серверного софта меня должны волновать микроконтроллеры? >Во-вторых, опять же там, где достаточно банального int размером 16-32 бита, вы предлагаете запихнуть целый класс Во-первых, шестнадцатиразрядные ОС уже давно ушли в историю. Во-вторых, вы упорно повторяете свою же придуманную идею про классы. Вы так и не почитали, как это под капотом устроено, а устроено оно достаточно эффективно. >Более того, если уж так зачесалось - то на С++ Вот самая большая проблема - убедить плюсовика в том, что портить память, спотыкаться на UB, жонглировать магическими константами, велосипедить прочие вещи - неправильно. Вы мне сейчас предлагаете всю стандартную библитеку переделывать, когда в том же Ocaml всё это уже есть из коробки >И лучше своё время потратьте на что-нибудь более полезное, чем бесполезные комментарии на форумах. На любом форуме нужно предупреждать новичков о существовании хороших языков, типа Ocaml, и языков для отстрела ног, типа си или плюсов. >Смотрите код, как обрабатываются атрибуты. Вы мне не поверите до тех пор, пока я вам не скину файл, который будет неправильно обрабатываться вашей программой? >Ну во-первых, она на С, а не на С++. И что? Найдите на плюсах, несколько минут поиска. >Но это не суть важно. Важно другое: как и писал выше - зачем? Вам не нужна корректная обработка xml? У вас плохо работает почти всё: и распознавание атрибутов, и значение этих атрибутов и так далее. Или вам нужно буквально скинуть файл, который ваша программа не распознает? Мне лень править файл. >А не ковыряться в незнакомом API, разбираясь, как его подогнать под выполняемые программой задачи. Я был о вас лучшего мнения. Вот что-что, а взять библитеку, и разобрать с её помощью xml - это гораздо проще, чем реализовывать парсер с нуля >Rust и прочие подобные ЯП пытаются решить ровно одну проблему: падение уровня квалификации программистов. А вы сами - квалифицированный программист? Ещё раз повторюсь, если вашей библитеке подать на вход специально созданный под неё xml, то она не сможет его правильно разобрать.
	Ответить | Правка | К родителю #420 | Наверх | 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++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Вы забыли заполнить поле 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ообщить модератору

	405. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 20:26
	>>Кэш > Я не помню точных цифр, но вместе с кешем хромиум собирался не > больше суток, а часов за шесть, что всё равно много. Поэтому в гугле используют распределенную сборку. Написал же. Ну и не только там если что.
	Ответить | Правка | Наверх | 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ообщить модератору

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

	392. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 13:49
	> То есть во-первых, старый парсер не следовал спецификации 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++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (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++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (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++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (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ообщить модератору

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

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

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

	441. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (449), 21-Сен-24, 21:18
	Мы разумеется поверим на слово вам, анонимный иксперт с опеннета, а не опытным разработчикам на Rust, подробно описавшим в своих статьях причины дороговизны разработки на этом языке.
	Ответить | Правка | Наверх | 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ообщить модератору

	388. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (89), 19-Сен-24, 12:49
	"Hello, World!" на Rust? Borrow checker-с, знаете ли.
	Ответить | Правка | Наверх | Cообщить модератору

	306. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (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ообщить модератору

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

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

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

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

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

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

347. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
Сообщение от Аноним (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ообщить модератору

	443. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (449), 21-Сен-24, 21:24
	Переучатся, куда денутся. Как будто это первое изменение стандарта, к которому нужно привыкнуть. Я тоже желаю успехов данному начинанию. Если получится, оно сделает Раст ненужным.
	Ответить | Правка | Наверх | Cообщить модератору

355. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
Сообщение от Аноним (-), 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ообщить модератору

	446. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (446), 22-Сен-24, 07:51
	> NVIDIA пишет драйвер на Rust, но тут многим виднее... И при чём здесь NVIDIA? https://www.opennet.ru/60821-nova
	Ответить | Правка | К родителю #355 | Наверх | Cообщить модератору

363. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–3 +/–
Сообщение от Другой Аноним (?), 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++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (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ообщить модератору

	387. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (274), 19-Сен-24, 12:45
	В С++ есть некоторые средства, снижающие риск, хоть и не убирающие его полностью: * std::vector и std::array вместо "сырых" массивов и их функция at() * Итерация контейнеров без указателей и индексов через for (auto& obj: container), std::for_each() Но иногда надо и проверять индексы, да. Например, получил какие-то данные из сети и парсишь их. Но и в таких случаях, если ты контролируешь формат обмена - можно использовать форматы обмена, для которых есть готовые библиотечные парсеры. Например, JSON, CBOR, Protobuf.
	Ответить | Правка | К родителю #376 | Наверх | Cообщить модератору

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

	398. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (-), 19-Сен-24, 18:46
	> Тогда чем это будет отличаться от условного Ocaml/Java, где границы точно так же проверяются? Сборка мусора? Джава машина? Функциональный или нет. Отличий куча. > Смысл плюсов в скорости, а с такими ручными проверками они её потеряют. Но смысла в типичный ошибках тоже мало. Менять скорость на дыры в крптогрфической либе, может только очень пофигистичный человек. Хочется спросить, а зачем тебе вообще эта либа? Тем более не все CVE это out-of-bounds. Use-after-free и double-free тоже весьма распространены. Но кроме них, есть еще множество ошибок которые легко решаются более продвинутыми языками. Например когда есть ENUM_1 и ENUM_2, естественно это инты, другое в дыряшке невозможно. И сравнивает пограммист (самый лучший) две переменных разных енумом... и все отлично сравнивается. > Тут уже ATS нужен или любой другой язык с зависимыми типами. Возможно это перебор. Тут староверы не могут осилить логику заимствования, а ты предлагаешь им покрутить лямбда-куб и погрузиться в кортежи и монады))
	Ответить | Правка | Наверх | Cообщить модератору

	399. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (374), 19-Сен-24, 18:55
	> Смысл плюсов в скорости, а с такими ручными проверками они её потеряют. Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массива. Брат жив,  рекомендую. Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороны. Предвижу ответ "Но я же потеряю одну секунду пока бегу за пивом!"
	Ответить | Правка | К родителю #397 | Наверх | Cообщить модератору

	401. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Fyjy (-), 19-Сен-24, 19:13
	> Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массива. Брат жив,  рекомендую. Думаю это редкость. У вас это правило в проекте или ты сам так решил? Если работаешь с коллегами, как они на это смотрят? > Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороны. Предвижу ответ "Но я же потеряю одну секунду пока бегу за пивом!" Ты не поверишь сколько таких умственно отсталых погибают под колесами каждый год. И главное когда его доктора собирают и спрашивают "О чем ты думал, дeбuл?" (c) то зачастую ответ "ну там автобус уже собирался уехать, я не хотел еще 10 минут стоять ждать" Так и в теме про уязвимость в очередной SSL начинается "проверки замедлят программу!"
	Ответить | Правка | Наверх | Cообщить модератору

	403. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (175), 19-Сен-24, 20:04
	>Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массива И что мешает это делать на языке где проверки делаются автоматически компилятором? >Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороны Если нужна производительность, то нужны и зависимые типы. Если производительность не важна, то зачем тогда нужен c++?
	Ответить | Правка | К родителю #399 | Наверх | Cообщить модератору

	411. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (411), 20-Сен-24, 00:39
	Мыши, станьте ежиками ))
	Ответить | Правка | К родителю #363 | Наверх | Cообщить модератору

383. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
Сообщение от Аноним (249), 19-Сен-24, 12:08
Кстати, походу Rust это только начало! На горизонте уже появляется "следующее поколение". Например, недавно наткнулся на вот такое: https://www.hylo-lang.org/ https://www.youtube.com/watch?v=5lecIqUhEl4
Ответить | Правка | Наверх | Cообщить модератору

	384. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+2 +/–
	Сообщение от Аноним (-), 19-Сен-24, 12:17
	> Кстати, походу Rust это только начало! На горизонте уже появляется "следующее поколение". > Например, недавно наткнулся на вот такое: > https://www.hylo-lang.org/ Конечно подражателей будет много. Если уже плюсовики задумались что "заимствование это круто", то более гибкие языки тоже могут заимствовать идеи. У некоторых будут новыи идеи, которые возможно перекочуют в раст. А может нет. Другие пока не приносят ничего супер ценного - как например зиг, который типа безопасный, но use-after-free позволяет. Будет ли hylo успешный? Может быть. Но протолкнуться в ядро, в дрова или андроид будет очень сложно.
	Ответить | Правка | Наверх | Cообщить модератору

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

	402. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (402), 19-Сен-24, 19:13
	На первый взгляд выглядит как наркомания. Объявлена непримиримая борьба не только с указателями, но и со ссылками. Вместо них предлагается писать какие-то subscripts, которые напоминают то ли питоновские генераторы, то ли плюсовые getter'ы на шаблонах. Дальше пошла квази-функциональщина, когда эти subscripts пихают в функции, и типа там должно что-то сгенерироваться без злых указателей, мягкое и плюшевое. На примитивных примерах то понятно, но не представляю как на этом писать что-то более сложное. Функциональщину вообще не перевариваю.
	Ответить | Правка | К родителю #383 | Наверх | Cообщить модератору

	410. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+1 +/–
	Сообщение от Аноним (411), 20-Сен-24, 00:37
	Язык с таким названием был бы настоящим подарком.
	Ответить | Правка | К родителю #383 | Наверх | Cообщить модератору

	445. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Kuku (?), 21-Сен-24, 21:44
	Да, но буковки "u" там все-таки не хватает
	Ответить | Правка | Наверх | Cообщить модератору

	416. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	+/–
	Сообщение от Аноним (416), 20-Сен-24, 11:30
	Раньше ради смеха си делали дифайнами внешне похожим на паскаль (фигурные скобочки бегин и энд заменяли) - ну хоть какая-то выдумка школьников. Сейчас просто взять Си и назвать его другим именем - норма. И обязательно рассуждения - как включить это в состав ядра. Отстаньте уже - займитесь делом.
	Ответить | Правка | К родителю #383 | Наверх | Cообщить модератору

	417. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (417), 20-Сен-24, 11:43
	> Сейчас просто взять Си и назвать его другим именем - норма. Это ти про сабж? Ну я бы сказал что он на СИ не похож совершенно. > И обязательно рассуждения - как включить это в состав ядра. Отстаньте уже - займитесь делом. А то что)? Будешь ныть? Мы как раз делом занимаемся, стараемся сделать ядро хоть немного лучше. И разгрести ту кучу кода, которую диды навалили.
	Ответить | Правка | Наверх | Cообщить модератору

	455. "C++ Alliance продвигает в C++ механизмы безопасной работы с ..."	–1 +/–
	Сообщение от Аноним (455), 03-Окт-24, 22:23
	ИИ разгребет, чисто вручную это малореально.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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