Президент организации C++ Alliance объявил о работе над спецификацией, добавляющей в язык C++ расширения для безопасной работы с памятью, напоминающих возможности, реализованные в языке Rust. Для осуществления проекта привлечён Шон Бакстер (Sean Baxter), автор экспериментального C++-компилятора Circle, развивающего идеи по повышению безопасности кода C++, реализуемые на стороне компилятора без использования сборки мусора. В рамках проекта Шон опубликовал документ с анализом применимости тех или иных мер защиты, предлагаемых в языке Rust, оценкой возможности их реализации для C++ и предложениями по добавлению в язык C++ расширений, повышающих безопасность кода...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61878
> C++-компилятора CircleУбийца Rust № 1.
Кто следующий?
Если в какой-нибудь C++2next примут, то все компиляторы станут убиийцами.
Смишно. Этот альянс -- сборище жуликоватых хитрованов. Зарегистированы, как торговая организация с очень интересными правами -- донаты юридических и физлиц не облагаются налогами, плюс исключаются из налогооблагаемой базы донатящих.Ну и фоты на интернет-простыне -- к ак говорится, бог шельму метит.
> Смишно. Этот альянс -- сборище жуликоватых хитрованов.The C++ Standards Committee - ISOCPP прокатит для твоего авторитета :D?
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34...
>> Смишно. Этот альянс -- сборище жуликоватых хитрованов.
> 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.
ЕНсть правило -- если функция что-то возвращает, возврат нельзя игнорировать или отдавать на откуп реакции по умолчанию. Все возвраты, особенно обернутые в исключения в С++, должны контролироваться, Иначе уровень программиста расти не будет, сколько бы он лишнего прикладного кода вместо контрольного не написал.
+100500% compilation times?
Ради такого дела и дела вытеснения Rust стоит подождать. Это лучше, чем +90 Gb для сборки Rust.
> Это лучше, чем +90 Gb для сборки Rust.А почему не 900 Gb? Слабенько набрасываешь...
>Это лучше, чем +90 Gb для сборки Rust.А зачем вы его пересобираете?
Как-то время скоротать, например. Видимо, других, более полезных занятий не нашлось.
Чтобы пересобирать, надо для начала хотя бы собрать.
beyond from beyond from rust
Бинарный кеш в ваших репах не изобретён?
Так-то и Раст довольно медленно компилиться, медленнее С++
Какое это имеет значение, если этим всё равно машины будут заниматься?
> Какое это имеет значение, если этим всё равно машины будут заниматься?Чинить и покупать они сами себя будут?
У типичной проги на расте тысячи зависимостей, суммарно миллионы строк. У типичной крестовой проги 1.5 зависимости завендорены в репозиторий. Но при этом время компиляции сравнимо.
Звучит как настоящее чудо. Поэтому хотелось бы увидет пруфы на данное чудо-утверждение.
Ёж++ птица гордая... Но лучше поздно, чем никогда. Ещё бы модули везде были.
Так боюсь уже поздно.
Просто представь новичков, которые ищут "а какой язык стоит учить?".
Если они поумнее и не хотят идти в вебкамаки на всяки JS/TS, то выбора из современных у них не так уж много.Если мобилки - то swift/kotlin, ну и всякие флаттеры.
Если серваки то там гошка и прочая вебня.
Если хочеться в геймдев (с кранчами по 80 часов) - С++.
Но не факт, что там будет это новый C++ Circle.
Значит или учить оба или выбирать.Чистую СИшку учить может только любитель всяких некропрограмм и легаси.
Т.к даже под микроконтролееры можно писать и на плюсах и на расте.Когда это примут, будет ли оно частью стандарта или просто сбоку прилеплено..
А тут уже есть Rust, который добавляют в ядро, на котором уже пишут проекты и даже ОС.
Выбор кажется очевидным.
> Если хочеться в геймдев (с кранчами по 80 часов) - С++.Но не факт, что там будет это новый C++ Circle.
В геймдеве в гробу видали как новые стандарты C++, так и стандартную библиотеку полюсов. А на вопросы безопасности там и подавно наплевать.
Ну, не то, что бы видали. Сам из геймдева. Стандартную библиотеку используем, ибо со своими граблями проблем больше. На соседнем проекте своя, но там исторически сложилось: игре порядка 15 лет, ещё под симбианы выпускалась. Да и то пытаются отвинтить.
Что касается новых стандартов, это похоже у всех в плюсах. И дело не в том, что не нужно, а в том, что:
1. Свежие стандарты сырые. Минимум следующий жди.
2. Не очень поддержка (в пример модули те же).
3. Переход бывает затратен без особого профита.
> В геймдеве в гробу видали как новые стандарты 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.
> Т.к даже под микроконтролееры можно писать и на плюсах и на растеТак можно хоть на луа писать, вот только пишут все равно на сишке.
Естественно.
У нас есть целые поколения покалеченные сишкой.. на чем им еще писать?
Когда тебе просто плевать на надежность кода и ты как "самые лучшие инжинеры тойоты" просто ребутаешь микроконтролер в случае ошибки, то можно и на дыряшке писать.А если нет, то испольузется Ada/SPARK.
Сейчас к этому списку может добавиться раст.
что вы носитесь из темы в тему с этой тоётой? какбудто она единственная кто пишит МК на сях, а остальные на божественном^W расте^W хз чём.
в чём язык виноват, если тоёта набрала чудаков
>Так боюсь уже поздно.Не поздно. Тот пресловутый корован, который, как бы, идёт, но только всё ещё больше лает, чем идёт.
> Не поздно. Тот пресловутый корован, который, как бы, идёт, но только всё ещё больше лает, чем идёт.А ты думал будет легко?
Что авгиевые конюшни овнокода разгребутся на раз-ва?
Что диды неосиляторы, которые одной ногой в маразме, скажут "да, конечно, я готов учить что-то новое"?Хаха, тогда твоя наивность просто необъятная.
Естественно копротивеление будет максимальное.
Понятно что старички будут держаться за насиженные теплые местечки и делать себе job safety любыми способами.И у меня очень большие сомнения, что в ядре будет успех.
Но это не значит, что не нужно было пробовать.
Вот коммитет С++ о чем-то тоже задумался
> "да, конечно, я готов учить что-то новое"как в анекдоте про байкеров "вы каждый год новые". Диды просто видят, что не осилят и свою работу и переписывание и видят, что осиляторов полным-полно
> как в анекдоте про байкеров "вы каждый год новые".Угу, думаю конюхи точно так же думали про эти ваши новомодные тарахтелки.
Мало того что жужжит, так еще и топливо в аптеке покупать нужно, оно воняет.. не то что родной конский навоз!> Диды просто видят, что не осилят и свою работу и переписывание и видят, что осиляторов полным-полно
Да, по кол-ву 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."
> Угу, думаю конюхи точно так же думали про эти ваши новомодные тарахтелки.А тарахтелки тоже появились сразу в неограниченном количестве? А новые типы тарахтелок с измененным интерфейсом "конюха" как часто появляются?
А тарахтелки уже имеют конструкционные зависимости от других тарахтелок?> Да, по кол-ву CVE видно как диды осиливают свою работу.
да я уже понял, что диды плохие. Я не понял, почему они должны что-то осиливать в отношении раста. Вообще не понимаю зачем чего-то требовать от плохих дидов, если можно сделать хорошо.
Сделаете хорошо -- диды останутся без работы и им придется выучить раст
> "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.
Хороший анекдот! Таки надо рассказать Сонечке (С)
Проблема не в осиляторстве. Проблема в том, что за это осиляторство платить никто не будет. Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок. Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечивать. Плюс пайплайн сборки курочить. На это добрый мес уйти может вполне, а за чей счёт?
> Проблема не в осиляторстве. Проблема в том, что за это осиляторство платить никто не будет. Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок.Просто так, ради искусства? Не, тогда не имеет смысла.
Или у нас просто куча багов, и пограммисты сидят днями раcковыривая очередной SIGABRT.
Их зарплату тоже нужно учитывать.Добавь сверху репутационные потери, например от порчи юзерских данных.
(Опенсорс проекты это не касается, тут народ привык "жрать чо дали" главное открыто и бесплатно).
А может еще штраф за утечку прилетит.. это у нас 40к рублей, а по GDPR может и 4% годового дохода.С этой точки уже не так и дорого может получится.
> Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечивать. Плюс пайплайн сборки курочить. На это добрый мес уйти может вполне, а за чей счёт?
Естественно за свой.
Вопрос что будет выгоднее, постоянно тратить деньги на заплатки и затыкание дыр.
Или переделать старое.
Особенно если достаточно сделать обертки и переписать самые стремные места.
> Или у нас просто куча багов, и пограммисты сидят днями раcковыривая очередной SIGABRT.только проблема в том, что куча багов у нас уже есть и теперь нужны еще программисты чтобы переписывать все.
Их зарплату тоже нужно учитывать.
А новые программисты нужны потому что
> Добавь сверху репутационные потери,из-за репутационных потерь мы не можем не фиксить ту кучу багов, что уже есть. И не выкатывать новые фичи, мы тоже не можем (хотя может и можем ограничить их количество)
А потом новый код надо будет еще усиленно тестировать, чтобы не появилось еще больше репутационных потерь.> Вопрос что будет выгоднее, постоянно тратить деньги на заплатки и затыкание дыр.
там еще вопрос, как потом жить с тем, что переписали. В погоне за переписыванием можно получить кадавра, в которого уже ничего нового нормально не добавить
> Особенно если достаточно сделать обертки и переписать самые стремные места.
и посчитать как эти обертки повлияют на производительность
> только проблема в том, что куча багов у нас уже есть иНа божественной сишечке куча багов? А не еретик ли ты))?
Но даже если эта куча есть, а вы еще не разорились.. то значит пользователи привыкли.> теперь нужны еще программисты чтобы переписывать все.
Выдели одного-двух, пусть работают по принципу парето и закрывают самые опасные участки кода
> из-за репутационных потерь мы не можем не фиксить ту кучу багов, что уже есть. И не выкатывать новые фичи, мы тоже не можем (хотя может и можем ограничить их количество)
Ты что взял и всю команду перекинул напереписывание?
Но зачем? У вас должен быть какой-то запас по капасити.
В крайнем случае, не все фичи одинаково полезны, и минорные низко-приоритетные можно отложить.> А потом новый код надо будет еще усиленно тестировать, чтобы не появилось еще больше репутационных потерь.
Судя по огромной куче багов - вы его вообще не тестируете.
Так что особо ничего не поменятся.> там еще вопрос, как потом жить с тем, что переписали.
А как люди живут, когда в проекте одновременно 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> В погоне за переписыванием можно получить кадавра, в которого уже ничего нового нормально не добавить
Ну так делай нормально, нормально и будет.
> и посчитать как эти обертки повлияют на производительность
Никак.
Уже считали, там на уровне погрешности измерений.
> На божественной сишечке куча багов? А не еретик ли ты))?так вроде никто не утверждал, что на божественной сишечке не делают логических ошибок
> Выдели одного-двух, пусть работают по принципу парето и закрывают самые опасные участки кода
ну то есть сделать как было в ядре. Там как раз было трое, но один уже не смог переписывать обвязки для раста с нужной скоростью
> Ты что взял и всю команду перекинул напереписывание?
а мы про какой проект говорим?
Про такой, где тысячи разработчиков и 1-2 будут переписывать долго и печально или про такой, где всего 1-2 разработчика?> У вас должен быть какой-то запас по капасити.
кому должен? У нас с тем кому должен товарно-денежные отношения?
> Судя по огромной куче багов - вы его вообще не тестируете.
тогда смысл от переписывания?
> А как люди живут, когда в проекте одновременно C, C++, Java и Kotlin?
там следующее предложение продолжает мысль. Зачем отвечать на часть мысли?
> Ну так делай нормально, нормально и будет.
а при чем тут раст?
> Уже считали, там на уровне погрешности измерений.
дай ссылку на исследование
> так вроде никто не утверждал, что на божественной сишечке не делают логических ошибокТак проблема не в логических ошибках.
Против них реально работает только формальная верификация - но это просто тонны денег.> ну то есть сделать как было в ядре. Там как раз было трое, но один уже не смог переписывать обвязки для раста с нужной скоростью
И в итоге ядро как было дырявым, так и осталось.
У нас же нет времени подождать, нам надо CVE плодить.> а мы про какой проект говорим?
про твой в 500k loc'ов
> Про такой, где тысячи разработчиков и 1-2 будут переписывать долго и печально или про такой, где всего 1-2 разработчика?У тебя 1-2 тащат такой проект в одиночку? Я им слегка сочувствую.
> кому должен? У нас с тем кому должен товарно-денежные отношения?
Себе хотя бы) Ну чтобы если вдруг заболел или вдруг второго разработчика сбил автобус, то не было просранных сроков.
Но если ты про опенсорс, то да, тут всем плевать на сроки, приоритезацию, планирование.
Как-то оно катится и пусть катится.> тогда смысл от переписывания?
Чтобы багов стало меньше)
Можно же переписывая часть багов исправить.>> Ну так делай нормально, нормально и будет.
> а при чем тут раст?Потому что ни на плюсах, ни на дыряшке уже пол века не выходит.
>> Уже считали, там на уровне погрешности измерений.
> дай ссылку на исследованиеможешь посмотреть бенчи
benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html
> Так проблема не в логических ошибках.Проблема, что их тоже надо исправлять
Но это не я еретиков каких-то рассмотрел> И в итоге ядро как было дырявым, так и осталось.
> У нас же нет времени подождать, нам надо CVE плодить.так а сколько ждать? В комментариях какие-то абстрактные требования и судя по всему в обычной манере "нужно вчера"
Как потребитель — я железки купил и мне нужна поддержка в ядре, а не ждать когда кто-то что-то перепишет.
Как разработчик — конкуренты тоже подождут?> У тебя 1-2 тащат такой проект в одиночку? Я им слегка сочувствую.
это не я предложил выделить 1-2 на переписывание без обсуждения сложности проекта
> Себе хотя бы)
себе я не должен работы, на которую нет спроса и которая не оплачивается.
Личные проектики — если он вдруг кому-то внезапно понадобилось (и они это как-то нашли), то сами перепишут, проекты конторы — контора не заинтересована.> Чтобы багов стало меньше)
> Можно же переписывая часть багов исправить.или наоборот добавить, гарантий никто не дает
> Потому что ни на плюсах, ни на дыряшке уже пол века не выходит.
так и причем тут раст? Судя по статьям, на раст выходит сильно по разному
> можешь посмотреть бенчи
там нет бенчмарков гипотетических оберток в гипотетическом проекте, гипотетически переписывываемом на раст
Вспомнил как "переписали" ioquake на раст, почти пять лет прошло. Я тогда почти поверил
Не знаю, как там на сях, у нас sigabrt 2-5 раз в год (по большей части либо в древнем C-style коде, либо в рендере OpenGL, где из-за критичности к скорости на расте скорее всего влепили бы unsafe). При этом гораздо больше проблем бывает с use after free на пуле (раст такое ловить не сможет скорее всего), когда нужно втыкать, какие переменные должны уйти в пул, а какие нет; анимациями, развалом контента. То есть, то, где раст мимо. И таким образом, ради пары багов год (по 2-4ч на каждый) должны потратить от мес до пары лет, дабы переплыть на раст?> порчу юзерских данных
Клиент мобильной MMO RPG. Не знаю, что там испортить можно. Да и по sigabrt данные скорее всего не запортишь. Быстрее другими багами (копипастой например).
> GDPR
Снова мимо: данные на сервере. Он на шарпах.
> естественно за свой
То есть мне, как программисту, предлагаете сидеть вместо 8 часов все 24 часа в сутки и отверженно переводить проект на раст?) Если для вас это норм, вы мазохист.
> самые стрёмные места
Не менее 30% проекта
>Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок. Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечиватьНужно переписывать плавно и неспеша. https://habr.com/ru/articles/511478/
>На это добрый мес уйти может вполне, а за чей счёт?Не важно. Поскольку функционал перетекает плавно, можно хоть десять лет делать. А делается это за счёт тех, кому данный проект нужен.
> Нужно переписывать плавно и неспеша.Статья про си. С плюсовым такое не проканает: минимальная переписываемая единица будет класс, да и то не всегда, если он покрыт шаблонной магией. А это от дня до недели разработки + тестирование
> А делается это за счёт тех, кому данный проект нужен
Им нужен проект и деньги с него, а не защита от каких-то мифических багов
>https://habr.com/ru/articles/511478/В статье сразу же:
"В предыдущей статье мы говорили о том, как избежать переписывания библиотеки на Rust, когда вам это не нужно."
"Джоэл Сполски гораздо лучше меня объясняет это в статье о том, почему полные переделки проектов — плохая идея."
А в статье "Огонь и движение" тот же Джоэль Спольски объясняет, почему (и для кого) переделки проектов - хорошие не только идея, но и дело.
Есть проект на коболе. Сколько нужно заплатить, чтобы переписать его на <...>?
Есть проект на фортране. Сколько нужно заплатить, чтобы переписать его на <...>?
Так вот, никто никому ничего платить не будет, поскольку все написанное на "опасных", бл..ть, для тупых программиздовъ языках, работает без осечек.
Пример: "дид" Д. Кнут xep знает когда написал TeX. Одна из тех программ, которые не нуждаются в постояном дописывании/переписывании. И никаких проблем с выделением/освобождением памяти и выходом за какие-то пределы там не наблюдается. Может просто признать, что 99% так называемых "программистов" тупые дoлбойoбы, не способные без сработавшего UB даже helloword написать.
> Может просто признать, что 99% так называемых "программистов" тупые дoлбойoбы, не способные без сработавшего UB даже helloword написать.О, ну это классика. "Зачем вы пишете с багами? Просто пишите без багов!".
> работает без осечек.Только если это хеллоуволрд)
Посмотри на ядро где менеджмент памяти до сих пор с базовыми ошибками, по мнению Торвальдса.
Или на ХОрг - просто куча овнокода, где ошибки живут по 30 лет.> Одна из тех программ, которые не нуждаются в постояном дописывании/переписывании. И никаких проблем с выделением/освобождением памяти и выходом за какие-то пределы там не наблюдается.
Отлично! Нам повезло и у нас есть одна программа, которая не подарит рут, когда ты в нее напишешь 28 бекспейсов!
> не способные без сработавшего UB даже helloword написать.
Что значит "сработавшего UB"?
UB оно или есть, или нету.
Причем что в дыряшке, что в плюсах int a + int b - это уже UB!
И по стандарту, результирующий код уже не strictly conforming.
Так что удачи тебе написать helloword, без UB. Спасибо качественному "стандарту"))
> Причем что в дыряшке, что в плюсах int a + int b - это уже UB!О, а что нам даст rust?
Он будет на всех вариантах процессоров ловить переполнение?
Или будет тратить время на предварительные проверки?
Каким из двух вариантов rust облажется?
Или то же приемлемое для скорости UB?
>Что диды неосиляторы, которые одной ногой в маразмеКак же вы задрали!
Всё что есть в индустрии - это написали мы, диды.
Пишем как считаем нужным и указывалка ещё у вашего поколения не выросла
>Всё что есть в индустрии - это написали мы, диды.Спасибо, диды, за IE 6, сам по себе такой бы монстр не появился. А ведь сколько подобных монстров диды насоздавали: SysVinit, bash, perl, make, autotools и куча прочего. До сих пор от всего не избавились.
> Чистую СИшку учить может только любитель всяких некропрограмм и легаси.
> Т.к даже под микроконтролееры можно писать и на плюсах и на расте.Можно. Но...
1) На сях вы будете выдавать продуктивный результат сильно быстрее чем на вон тех кошмариках.
2) safety critical и прочие требовательные штуки на сях - тупо проще и быстрее, из-за педальности его окружения и минимализма рантайма, особенно ежели без stdlib'а.А про C++ хорошо написали в книжке "Scalable C". И хотя это весьма biased и специфичное чтиво от автора ZMQ - но плюсам оно наподдает весьма за дело. Все перечисленные проблемы я там видел лично. В том числе и уход кодеров в астрал^W использование своего субдиалекта, а потом... потом... потом этот код майнтайнить никто не может и наступает - ж@па! То что делает 1 кодера мощнее не обязательно что круто при командной игре.
> safety critical и прочие требовательные штуки на сях - тупо проще и быстрееСлава богу, в safety critical сишку чаще всего не подпускают на пушечный выстрел. Иначе бы был целый самолетопад.
А где пускают - то там всякие мисры, которые к си отношения практически не имеют, один синтаксис общий.> использование своего субдиалекта
Не хуже чем написание своих велосипедов на си, когда чего-то не находится в стандартной либе.
Вон недавно свой сплит писали... и дописались до CVE.
> Можно. Но...
> 1) На сях вы будете выдавать продуктивный результат сильно быстрее чем на вон тех кошмариках.Что такое "продуктивный результат"?
Если х-к-х-к и в продакшн, то да.> 2) safety critical и прочие требовательные штуки на сях - тупо проще и быстрее, из-за педальности его окружения и минимализма рантайма, особенно ежели без stdlib'а.
Но почему-то все равно пишут на ADA/Spark))
Потому что убогость в которой дыреней больше чем в швейцарском сыре, нужна только там где другого не знают.
Вот появится там хотя бы defer из коробки, тогда мождно будет говорить))> А про C++ хорошо написали в книжке "Scalable C". И хотя это весьма biased и специфичное чтиво от автора ZMQ - но плюсам оно наподдает весьма за дело.
Так biased или за дело?
Если у тебя какая-то сложнейшая задача - например писать в одну и ту же память одновременно с кучи потоков...
Но везде ли есть такое?> Все перечисленные проблемы я там видел лично. В том числе и уход кодеров в астрал^W использование своего субдиалекта, а потом... потом... потом этот код майнтайнить никто не может и наступает - ж@па! То что делает 1 кодера мощнее не обязательно что круто при командной игре.
Ой, а типа у нас в ядре не свои гнутые экстеншины?
И 20 лет вендорлока на один раковый компилятор?Ты ж понимаешь, что на любом языке можно сделать свой диалект, хоть на СИ, хоть на JS.
Накрутить абстракций или сложных алгоритмов..
Ну чтобы быть незаменимым.Т.к мы говорим про микроконтролеры, то думаю ты в курсе про Тойоту и их "шЫдевр".
Функция с цикломатикой в 150.
На такое мало кто способен.
Чел, этот миф про субдиалект уже всем порядком надоел. В любом тьюринг-полном языке можно выработать свой особый стиль написания кода.
Си, к слову, ещё хуже, так как то, что решается из коробки плюсовыми шаблонами и consteval'ом, решается в Си через такой жуткий костыль как макросы, и то не полностью.
С МК у раста пока не шибко хорошо. Какие-нибудь arm - норм, а вот тот же avr, на сколько знаю, ещё в третьей стадии поддержки
> С МК у раста пока не шибко хорошо. Какие-нибудь arm - норм,
> а вот тот же avr, на сколько знаю, ещё в третьей стадии поддержкиВообще не вижу смысла в avr для новых проектов. Вот совсем.
Для новых есть сотни вариантов stm32, причем младшие дешевле avr и производительнее.
Есть прочие ARMы, есть ESP32, есть еще куча других.
А старые никто переписывать не будет.Но если вы в теме, может опровергнете такое мнение.
> Выбор кажется очевидным.JAVA ?
> Чистую СИшку учить может только любитель всяких некропрограмм и легаси.
> Т.к даже под микроконтролееры можно писать и на плюсах и на расте.Чтоб рожать бинарники размером с ROM?
Я тя расстрою, DSP/MC и вообще embedded еще и на ассемблере пишут.
> растущую в среде разработчиков потребность в безопасных методах программированияЭталонная подмена понятий. Браво.
Какие именно понятия тут подменили?
Подмена в том, что это не разработчикам, а крупным клиентам корпооаций надо (и самим корпам!)
Ну а разрабы 99% работают "на отъе..сь", ну а конечным покупателям кто ж обеспечит безопасность за те копейки, которые они платят?..
> Подмена в том, что это не разработчикам, а крупным клиентам корпооаций надо (и самим корпам!)А ты в курсе, что разработчики - это работники тех самых корпораций? И задача их буквально состоит в решении проблем корпораций.
зачем ему на такие мелочи обращать внимание. он отважный диванный борец с корпорациями, четкий бородатый админ на бюджете. его красные глаза наполняются слезами, когда видят как злобные корпы угнетают все открытое и доброе
Оно скорее больше юзерам нужно, а не разрабам.
Потому что их задобало, что им могут ломануть напр. телегу или фейсбучек просто прислав картинку.
Ну а какой умелец в либе разбора не проверил входные данные и всё - кровь, кишки...
А юзеры в свою очередь делают дырку в голове корпам, предоставляющим сервис...
Да и просто новости про дыры хорошо тиражируются журналистами и немного портят настроение совету директоров)))
> Потому что их задобало, что им могут ломануть напр. телегу или фейсбучекЛомануть Фейсбучек - смишно. Те, "кому положено" и "там разберутся", в Фейсбучеках и без взломов пасутся.
> Те, "кому положено" и "там разберутся", в Фейсбучеках и без взломов пасутся.Да. У них есть если не прямой доступ, то доступ по запросу "выгрузите мне все". И с этим ты ничего не сделаешь.
Но речь не про них. А про угоны самих учеток для рассылки спама и просьб "дай 2000 до следующей зп".
Про майнеров, который через браузер пролазят, про шифровальщиков, про скраперы банковких данных и тд.
Сейчас это все чуток сложнее стало делать, обновлением флешплеера не отделаешься.
А вот регулярные дыры очень помогают.
В C++ первым делом нужно добавить стандартные профили, ограничивающие некоторые возможности языка (вроде арифметических операций с указателями или вообще доступность указателей как таковых) по требованию и более полно определяющие поведение в различных ситуациях.
> и более полно определяющие поведение в различных ситуациях.Может ты еще и UB предложишь убрать??
На последние скрепы решил покуситься?!
На костер еретика!
Нет стандарта - нет UB.
Так это уже можно сделать. Определить шаблоны, перекрывающии такие операции, но без реализации или со static_assert(false) и линковка/компиляция начнёт падать. Тут, скорей, проблемы не только в указателях, но и в ссылках на объекты, у которых может истечь время жизни раньше разрушения объекта с ссылкой.
С любыми этими профилями это уже будет не C++. Делайте свой язык, а там видно будет.
Если это будет строгое подмножество, то это все еще C++.
Вот только это уже будет не С++, сломается обратная совместимость, деды и тут будут недовольны.
Гы, считай что в каждом стандарте плюсов есть "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[]
Это еще дожить надо до "removed"... std::auto_ptr с момента внесения до удаления жил 19 лет в стандарте.
Да пох на этих дедов, ни один компилятор не соответствует стандарту на 100%, а значит, в общем случае невозможно написать корректный кроссплатформенный код. Либо корректный, либо кроссплатформенный (и то второе не гарантируется).
> Вот только это уже будет не С++, сломается обратная совместимость, деды и
> тут будут недовольны.Ну так пусть и компилят под свой замшелый стандарт типа CPP98, никто ж не запрещает! ;). Просто придется сказать "проект юзает C++98". А не C++23 или сколько там.
> Ну так пусть и компилят под свой замшелый стандарт типа CPP98, никто ж не запрещает! ;).Ты тут такого не говори (с)
> Просто придется сказать "проект юзает C++98". А не C++23 или сколько там.
Нытье и вой будет.. до небес)
Понятно что обратная совместимость это хорошо, но меру надо знать.
А у комитетчиков (что СИ, что плюсы) ее нету.
Так и будут тянуть поддержку инструкций для всяких допотопных архитектур "а вдруг кто-то найдет на складе 100500 миллионов 8008"
> сломается обратная совместимостьКаким образом, если проверка только на стороне комрилятора?
>> сломается обратная совместимость
> Каким образом, если проверка только на стороне комрилятора?Не знаю.
Но разработчики стандарта такие затейники, что думаю что-то придумают.
Например в C23 они поменяли zero-sized reallocations with realloc are undefined behavior.Т.е был валидный код
void *ptr = malloc(0);
free(ptr);а вот
void *ptr = malloc(4096);
ptr = realloc(ptr, 0);
уже UB на откуп разработчикам компилятора.
таким, что если раньше какие-то хаки были "ничего", то теперь компиллер откажется это собирать или будет сыпать ворнингами.
Порог входа неуклонно растёт, а количество полностью знающих язык и его стандартную библиотеку падает.
неправда, книги как были около 1300 страниц в 2003, так и остались по с++23
> книги как были около 1300 страниц в 2003Так ты забыл умножить количество страниц на количество стандартов. В новых книгах и акцент на новом.
ну так а нефиг в 2024 писать while(*dst++=*src++)
Только что писал для выноса анимации в вебе на C/WASM. Видишь ли libc чтобы дёрнуть memcpy нет в среде исполнения Wasm.
Как правильно заметил анон выше - умножь на количество стандартов.
А потом еще умножь на количество самых распространенных компиляторов.
Ну чтобы не сесть в лужу, когда делаешь простейши действия.
N4860 - 1829 страниц.
[учебники] и [спеки] - это, какбы, разные книги
Я могу написать отчет строго по внутренним стандартам компании на 300 страниц, а могу его же написать по делу, будет 30, так и с книгами. Порог вхождения действительно растет, с учетом того, что системы усложняются, все это умножается на повесточное образование и вуаля, реальных спецов становится все меньше.
Это нормально. Со временем комитет осознаёт, какие вещи наиболее востребованы среди программистов и стандартизирует подход.
> Со временем комитет осознаёт, какие вещи наиболее востребованы среди программистов и стандартизирует подход.Для стандартизации подхода нужно будет создавать отдельный коммитет или можно использовать текущий?
Нужна ли стандартизация подходов стандартизации?
Может ли случиться рекурсивное создание коммитетов или уход текущего в бесконечный цикл?Столько вопросов на которые нет ответов (((
Другие языки тоже обрастают фичами. Я думаю, немногие питонисты или яваскриптчики знают вот прямо абсолютно все фичи Питона или Яваскрипта.
> стандартную библиотекуСтандартная библиотека Явы гораздо больше, чем у С++, все её уголки тем более никто не знает. Однако же пишут как-то на Яве. :)
Даже более того, её кто-то да знает. Например, сами разработчики из Oracle.
Имеется ввиду, что ни один человек её целиком от и до не знает. Разумеется эти знания размазаны по большому числу людей...
> Стандартная библиотека Явы [ ... ], все её уголки тем более никто не знает- JavaDoc?
- Не-е ... Не слышали ...
И Doxygen, ага. Что сказать-то хотел?
У меня ощущение, что порог входа наоборот падает. Раньше без арифметики указателей ничего не сделать было, а сейчас приучились все на векторах и shared_ptr делать, где надо и где не надо...
Был проект по добавлению аннотаций времени жизни в Clang C++, но почему-то сдулся: https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/...
Какой только хернёй они не занимаются, чтобы только не переходить на Раст...Не получится навязать готовому языку безопасность в виде костылей.
Нельзя было что-ли сделать раст нормальным языком? Тогда бы все на него перешли.
Rust - это нормальный язык. В чем-то даже офигенный. Просто факт в том, что не все иксперды с OpenNET способны его осилить.
Реально некоторые косяки есть не с самим языком а с отдельными вещами в стандартной библиотеке Rust, но их, при желании, так или иначе можно обойти.
Ясно, не язык плохой, а программисты плохие. Где-то мы это уже слышали.
Вы таки думаете, что среди хаящих Rust икспердов с OpenNET есть программисты?
Проблема в обратном что программистов на Rust мало среди фанатиков Rust.
Давно уже есть smart pointers в C++. unique_ptr с move semantics это то что в Rust реализуется как владение (ownership) с той разницы что в C++ это не реализовано на уровне компиляции программы, а во время выполнения. Что мешает делать подобные вещи во время компиляции? Ничего.
> move semantics это то что в Rust реализуется как владение (ownership)Эмм... Нет, это вообще практически не связанные вещи.
В плюсах компилятор не знает и знать не может, что ты там внутри своих unique_ptr делаешь.
нет
в C++ move-семантика изначально убогая, т.к. делалась с оглядкой на обратную совместимостьискать "c++ destructive move", если что
А в чем костыль? В компилятор не смогут реализовать статическую проверку памяти для C++?
При наличии indirect pointers? Флаг вам в руки и ветер в спину.
Другое дело что ownership (владение) давно уже реализовано в Spark (язык Ada) и было заново переизобретено в Rust
ownership всегда было известно тому кто хотел его знать, с момента изобретения динамического выделения памяти.
Зачем, переход ради перехода? Для каждой задачи/бюджета свой инструмент. Если сегодня устроить тендер на 10 млн долларов, написание Вордпад на С++, так чтобы код был безопасным, думаете спецы не справятся?-)) А если справятся, значит С++ проблем не имеет или имеет?
> Зачем, переход ради перехода? Для каждой задачи/бюджета свой инструмент.Потому что уже сейчас есть рабочий интрумент, который успешно применяется например в андроиде.
А с другой стороны - планы когда-то сделать возможно крутую штуку, но в году так 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
1. зачем чучхе, вместо интеграции в clang и LLVM?
2. Есть же уже Cabron.
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"
Как будто сабж не экскрементальный.
Swift и Kotlin будут получше и перспективнее с точки зрения работы. В Swift также есть Automatic Reference Counting (ARC), что гораздо более практично для безопасного управления памятью.
Гугли, после того как их выкинули из С++ комитета за попытку загнуть плюсы под свои хотелки, высрали кирпичей и один из них оказался карбон. Но как оказалось звездеть о новом убийце плюсов проще чем создать востребованный язык и потому карбон так и остался кирпичом.
Бедный Гугл быстро нашел раст на замену плюсов (для нового кода).
А гордый коммитет сейчас питыется лепить костыли.Может если бы послушали гугловцев, то идеи начали реализовывать лет 5-8 назад, а не только начинать разглагольствовать.
Даже нового кода на расте Гугл пишет очень малую долю.
> Есть же уже Cabron.Да, есть. И даже не один. Только это - не ЯП. Посмотрите перевод слова "cabron" с испанского...
Я как бы знаю, игра слов намеренная.
> Я как бы знаю, игра слов намеренная.Ну тогда будем считать, что я шутку оценил))
Теперь еще это в сишку, чтоли, запилить - и вообще нормуль. А то плюсы - больно уж навороченные. И это вовсе и не фича даже.
Уже запилили: https://en.wikipedia.org/wiki/Zig_(programming_language)#Memory_handling
О... опять эта поделка.
Когда оно мне попадалось пару лет назад на глаза, то позволяло весело и непринужденно делать всякие непотребства.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
оно еще очень сырое.
Пару лет назад это вечность для нового языка. Сейчас многие переходят на Zig, разочаровавшись в Rust, так что его развитие заметно ускорилось. У него больше перспектив.
>Уже запилили
>First appeared 8 February 2016; 8 years ago
>Preview release 0.13.0Сейчас языка нет, есть только идея языка, без обратной совместимости. И с учётом времени прошедшего после начала разработки, в ближайшем времени ничего не будет. Если иметь чёткое представление, что должно получится, то можно за условные пару месяцев реализовать первую версию, и объявить о стабилизации апи, после чего можно годами неспешно расширять библиотеки. Если же чёткого представления нет, то будут пробы разных подходов, с отказам от них, что выльеться в постоянное переписывание разных частей.
> можно за условные пару месяцев реализовать первую версиюПара месяцев это для новичков.
Ты за 21 день бы сделал новый язык
>Если иметь чёткое представление, что должно получится, то можно за условные пару месяцев реализовать первую версию, и объявить о стабилизации апи, после чего можно годами неспешно расширять библиотеки.Что же тогда разработчики Раста не использовали этот разумный подход, а вместо него:
>Если же чёткого представления нет, то будут пробы разных подходов, с отказам от них, что выльеться в постоянное переписывание разных частей.
>Что же тогда разработчики Раста не использовали этот разумный подход, а вместо него:Раст уже давным давно зарелизил 1.0, и имеет обратную совместимость https://doc.rust-lang.org/edition-guide/editions/
Это костыль для отмазки, а не обратная совместимость. По факту старую прогу на Расте фиг соберешь без бубна.
Не осиливаешь все навороты - пользуйся только тем что осиливаешь. Никаких проблем с этим нет.
Шаблоны мощная штука - но многие их реализации практически нечитаемы и сложны в понимании и отладке.
"Сначала они тебя не замечают, потом смеются над тобой, затем борются с тобой. А потом т̶ы̶ ̶п̶о̶б̶е̶ж̶д̶а̶е̶ш̶ь̶ они начинают копировать твои идеи"Вот оно признание от плюсовиков:
что их язык из прошлого века не может обеспечить нынешние требования к программам,
что есть идеи которые позволяют сделать лучше,
что надо что-то делать...Но думаю если оно пойдет в стандарт, то это будет в году так 2030 или даже позже.
Пока коммитет позаседает, пока все обсудят...
Ну и слом совместимости (особенно в мозгах дидов) тоже неизбежен.
>#feature on safetyВ C и C++ для этого используются #pragma
Точно. на текущий момент есть always acceptable
#pragma region ....
#pragma endregion ....Реализовать логику #pragma region safe/unsafe Особой проблемы нет.
> переводить проекты на безопасные методы, сохраняя при этом совместимость с уже существующим "небезопасным" кодом.Странная идея. Нужен Раст - берите Раст, в чем проблема-то?
Если эту спеку и примут, то сперва бюрократы из комитета C++ будут мусолить ее лет шесть, а потом еще лет шесть-десять придется ждать ее сколь-нибудь сносной поддержки в компиляторах. Обалденный план с учетом того, в Расте все эти упомянутые фичи работают прямо здесь и сейчас.
Ну и самое главное: кто-то всерьез считает, что все так и ломануться переводить свои десятилетиями пишущиеся легаси-копролиты в миллионы строк C++ на эти новые костыли?
Тяжело им в Rust идти. Вакансий нет и специалистов нет.
Как они пойдут сами что ли проичтабт книжку?
Просто выкинут раст и всё.
> Странная идея. Нужен Раст - берите Раст, в чем проблема-то?Тогда г-н Vinnie Falco не сможет влиять на развитие языка и на программеров, которые им будут пользоваться.
Когда у тебя есть власть, то всегда хочется еще.> Ну и самое главное: кто-то всерьез считает, что все так и ломануться переводить свои десятилетиями пишущиеся легаси-копролиты в миллионы строк C++ на эти новые костыли?
Ну.. во-первых были бы деньги)))
Во-вторых - даже если завернуть в эти костыли какие-то особо кривые куски кода, типа парсинг пользоватльского ввода - то уже стало бы гораздо лучше.
Но да, возникнет вопрос "а чего не создать раст обертку?" Как поступает например гугл.
Проблема в том, что это другой, несовместимый с C++ язык, который хорошо знают только его создатели.И для него в первую очередь справедливо утверждение
>кто-то всерьез считает, что все так и ломануться переводить свои десятилетиями пишущиеся легаси-копролиты в миллионы строк C++ на эти новые костыли?тогда как на новый C++ переписать его будет вполне реально.
>mut
>std2
>safeМожно хоронить. Плюсовые компиляторы сами умеют определять. Вместо того, чтобы всё вручную аннотировать, нужно развивать встроенный статический анализ.
> самиНеверно.
Проблема pointer provenance до сих пор не решена в силу ее сложности. См. статьи Ralf Jung.
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 компьютеры были медленные, а компиляторщики пролоббировали свои интересы в комитете (чтобы им было меньше работы).
> 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))?> а компиляторщики пролоббировали свои интересы в комитете (чтобы им было меньше работы).
Думаю проблема была в том, что уже были написанны тонны кода с разным поведением.
И никто не хотел оказаться за бортом.
Чтобы никого не обидеть - постановили "на усмотрение компилятора, пусть творит что хочет".
> Но хотя бы определение 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++: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
)
Видимо ты не знаешь о существовании -Weverything
Явное указание все опций не сломает сборку на новом компиляторе, если в эврифинг что-то добавят.
> Явное указание все опций не сломает сборку на новом компиляторе,Каким образом предупреждения могут сломать сборку?
>> Явное указание все опций не сломает сборку на новом компиляторе,
> Каким образом предупреждения могут сломать сборку?-Werror
-Werror не входит в -Weverything.
учи матчасть. ты понятия не имеешь, о чём говорят в этой ветке.
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> учи матчасть. ты понятия не имеешь, о чём говорят в этой ветке.... и кидает ссылку да доку GCC.
Чел, -Weverything - это опция clang. Хотел поумничать, но как всегда сел в лужу.
тебе про Фому, ты про Ерёму. иди читай, что такое -Werror
-Werror
-Werror - это не предупреждение и в -Weverything не входит 🤦
> -Werror - это не предупреждение и в -Weverything не входит 🤦И дальше что? Оно указано отдельно в начальном комментарии.
> И дальше что?То, что ты умничаешь в ветке, где ответили на:
> Явное указание все опций не сломает сборку на новом компиляторе, если в эврифинг что-то добавят.
Опять кексперт пытается поднять своё эго в комментариях. Изначально обсуждались конкретные опции и там был werror, перечитай ветку.
> Изначально обсуждались конкретные опции и там был werror, перечитай ветку.Нет, обсуждалось конкретно твое заявление "Явное указание всех опций не сломает сборку на новом компиляторе, если в *эврифинг* что-то добавят".
Когда тебе написали, что новые проверки -Weverything сломать ничего не могут (ибо они только предупреждения), ты в ответ с умным видом упомянул -Werror. Который вообще сам по себе не ворнинг и потому в -Weverything никогда не будет добавлен.
Ну а потом твои аргументы вообще съехали в "и что дальше?" и "кексперт".
Опять экперт уровня "слышал звон" пытался поумничать, но сел в лужу...
>> Изначально обсуждались конкретные опции и там был werror, перечитай ветку.
> Нет, обсуждалось конкретно твое заявление "Явное указание всех опций не сломает сборку
> на новом компиляторе, если в *эврифинг* что-то добавят".Выше читай https://www.opennet.me/openforum/vsluhforumID3/134833.html#37 и https://www.opennet.me/openforum/vsluhforumID3/134833.html#36 где и указаны опции и если бы ты внимательно почитал, то увидел бы там -werror.
Лучше, если сломает. Явное лучше неявного.
> Лучше, если сломает. Явное лучше неявного.Явно перечисленные предупреждения лучше чем неявно, скрытые в чем-то другом.
Ещё бы к этому добру аналог: cargo fix
Позитив. Ибо нефиг выпендриваться. Тоже могём.
Раст здорового человека.
Вот, теперь C++ начало этим заниматься, потому что есть потребность в это. В первую очередь, потребность США по кибербезопасности.
> Вот, теперь C++ начало этим заниматься, потому что есть потребность в это.
> В первую очередь, потребность США по кибербезопасности.Им потребно наличие бэкдоров. На расте можно встроить прямо в компилятор, затимв разум неокрепшим умам верой в безопасность.
> Им потребно наличие бэкдоров.Всем потребно. Но кроме бекдоров есть еще и дыры.
И они не хотят, чтобы их ломали через эти дыры всякие узкоглазые и чучхе.> На расте можно встроить прямо в компилятор
Можно. И в сишку можно.
Но в сишке проще на null проверочку забыть.
>> Им потребно наличие бэкдоров.
> Всем потребно. Но кроме бекдоров есть еще и дыры.
> И они не хотят, чтобы их ломали через эти дыры всякие узкоглазые
> и чучхе.В эту игру в одного не играют.
>> На расте можно встроить прямо в компилятор
> И в сишку можно.Компилятор для си можно забутстрапить, притом там все начинается с простого компилятора, написанного на scheme, которым уже потом собирается tcc. Кто собирает раст? Где исследование исходников на бэкдоры? Одна реализация по факту, все качают бинари. Куда проще встроить?
В эту игру играют в OpenSorce ПО.
Ты не понял.
> Компилятор для сиКакой именно)? У нас их просто куча! Даже пованивает, тк минимум половина уже померла и разложилась.
> притом там все начинается с простого компилятора, написанного на 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 лет.
> Раст кстати тоже можно бустстрапить
> 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? Это бред.
>То есть на первом шаге бутстрапинга предлагается скачать бинари компилятора и cargo? Это бред.Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. А вы что предлагаете, скачивать llvm ir код? Для тех, кто не доверяет текущему компилятору есть возможность собирать его версию за версией, начиная с той, что написана на ocaml.
> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки.И стадию внедрения бэкдора. Это не бутстрапинг. Почитай как сделано в gnu mes.
>> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки.
> И стадию внедрения бэкдора.Бремя доказательства лежит на утверждающем. Даже если он балаболка.
Но пруфов от тебя, я даже не надеюсь увидеть> Это не бутстрапинг. Почитай как сделано в gnu mes.
Жду определение bootstrapping, где сказано что так делать нельзя)
То что ГНУтики делают как-то по другому не говорит ни о чем.
Они могут хоть мозоли кушать, хоть коммуизм продвигать, это не повод за ними повторять.
>>> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки.
>> И стадию внедрения бэкдора.
> Бремя доказательства лежит на утверждающем. Даже если он балаболка.
> Но пруфов от тебя, я даже не надеюсь увидетьКачай бинари с интернета и запускай локально, кто тебе мешает. А как надо бутстрапить читай как уже выше сказал в gnu mes.
>> Это не бутстрапинг. Почитай как сделано в gnu mes.
> Жду определение bootstrapping, где сказано что так делать нельзя)
> То что ГНУтики делают как-то по другому не говорит ни о чем.В основе бутстрапинга не может лежать неиследованный бинарь.
> Они могут хоть мозоли кушать, хоть коммуизм продвигать, это не повод за
> ними повторять.А, ну понятно с тобой все.
> И много людей собирают из исходников GCC и CLang?Clang хз, gcc - да.
> Зачем что-то встраивать в компилятор, если проще сделать out-of-bounds прямо в коде?За свой код ответственнен ты. За компилятор нет, как и за уровни ниже. Разницу понимаешь?
> У нас их просто куча!А знаешь почему? Потому что есть стандарт.
> Даже пованивает
Пока тут ты пованиваешь только.
>Потому что есть стандарт.Конечно, причина не в этом. Обусловлено это всё относительной простотой языка и разнообразием архитектур. Отсутствие стандарта для того же Rust не помешало разработчикам gcc начать создание для него компилятора.
Начать, начать, Карл!
Закончить помешало. Как обычно.
Бэкдоров полно, что в ПО, что в процессорах. У США явно будет/есть возможность получить к ним доступ. А обезопасить свою инфраструктуру не только от бэкдоров, но и багов - это задача. Уязвимости, связанные с памятью - самые распространенные, поэтому Rust привлекателен.
> Уязвимости, связанные с памятьютам выше мой комент как раз про это - скрыли, ну пусть с такой же "пеной у рта" придумают "безопасТную модель памяти", а не 1000500-ый "безопасТный механизм" работы с "небезопасТной моделью памяти".
Твой комментарий выше - это мешанина тёплого с мягким, или мух с котлетами. Небезопасные языки добавляют проблем к потенциально нестабильной работе аппаратной памяти. Люди пытаются с этим бороться с помощью безопасных языков. Вроде, простая мысль. А поди ж ты, приходится разжевывать.
> Твой комментарий выше - это мешанина тёплого с мягким, или мух с котлетами.а кто-то отменил существование котлет из мух? азиаты с вами бы поспорили бы, у них там бигмак из тараканов есть, это как про "мешанину Канта", Кантом надо быть, чтобы понять, короче, проехали.
> Небезопасные языки добавляют проблем к потенциально нестабильной работе аппаратной памяти.
Нету такого определения "небезопасТные" или "безопасТные" языки. Определение "потенциальная нестабильность" не приемлема там где необходима "надежность" аппаратная. Вы хотите сказать, что допустимо, что-либо "аппаратно-нестабильное" использовать там где необходима "надежность"?
> Люди пытаются с этим бороться с помощью безопасных языков.
Нету определения "безопасТных" языков. То есть люди должны были строить мельницы не похожие на мельницы, чтобы доны Кихоты с ними не сражались, за место того, чтобы лечить самих донов?
> Вроде, простая мысль. А поди ж ты, приходится разжевывать.
Ну да, простая, вот и я разжевал:
«Класть все яйца в одну корзину» — народная поговорка, которая говорит о том, что как раз не стоит этого делать. Потому как положил все яйца в одну корзину, уронил ее нечаянно — и остался без яиц.
> что в процессорахПоэтому важно в этом направлении тоже развиваться.
> поэтому Rust привлекателен
Пока что это решение вендорлок, со стремным вектором развития, одной реализацией, странным сообществом.
> Пока что это решение вендорлок,Что правда?
Там те самые компании в foundation'е сидят, что и в ядре.
И почти те же самые корпорации, что в коммитете С++.> со стремным вектором развития,
стремное - это твое мнение, на которое, как ты догадываешься, всем плеевать
но зато развитие есть, а не деградация> одной реализацией,
Неправда, есть как минимум 2 компилятора + еще несколько надстроект ferrocene.
Другое дело, что тут нет такого "мы не знаем как сложить 2 числа, пусть разработчики компилятора как-то сделают"> странным сообществом.
Тоже оценочное мнение. На код и его работоспособность не влияет.
Я понимаю, что многие по понятиям начинают заглядывать разработчикам в труселя...
cargo, доставка on-the-fly, и т.д. Конечно, rust привлекателен. Для доставки чего надо куда надо.
> В первую очередь, потребность США по кибербезопасности.они 4 летний опыт работы отменили буквально на днях, делайте вывод.
Я как программист полностью одобряю: теперь мне ту же работу нужно будет делать в 5 раз дольше, а мне кредит за дом платить и вообще деньги откладывать. а на плюсах быстро всё сделал и не остаётся уже, что делать
Глупости ты говоришь.
Да возможно переписать займет не год, а пять..
(в чем я очень сомневаюсь тк гугл переучивает 2/3 гошников и фортовиков на раст, за 2 месяца!)А если писать на С - то можно годами ковырять древние баги, которым по 20-30 лет, и создавать новые, для будущих поколений.
Как в том анекдоте про адвокатов "Что же ты сынок наделал! Это дело нас уже четверь века кормило!!"
> а на плюсах быстро всё сделал и не остаётся уже, что делатьВ смысле "не остается"?
Если в плюсах "быстро все сделал", то у тебя еще на полгода вперед будет работы над списоком багов из-за висячих ссылок, протухших итераторов, выходов за пределы буфера, UB и прочих C++ чудес.
Ты наоборот должен быть против!
>выходов за пределы буфераИспользуй умные указатели.
>UBВ C++ используются нормальные строки, это уже улучшает ситуацию значительно.
>Используй умные указатели.В лучшем случае получится только в своём коде, но не в библиотечном.
А, ну да, Rust же не используют библиотеки, написанные на C.
Какое мастерское приплетание Расте в ветке обсуждения C++...
Какой детский уход от темы.
Если уж брать раст, то там можно взять банальный grep и проверить. А вот в плюсах - нельзя. И говоря про выход за границы, то непонятно, это обычный массив, или оператор индексации. Это уже как минимум языковой сервер нужен
Так используй языковой сервер и статические анализаторы, на дворе 21 век все-таки.
> теперь мне ту же работу нужно будет делать в 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 раз [в два раза] дольше, а мне кредит за дом платить и вообще деньги откладывать...". А главное! главное! - потом годами сопровождать, ошибки искать и фиксить. Главное неспеша, по одной, чтобы до пенсии хватило. Ну прям как в том анекдоте про юристов отца и сына.
Да ты это уже раз 50 в комменты вставлял. И одно это говорит как мало положительных отзывов о внедрении Rust в реальные проекты.
Надо добавить все фичи всех языков... и не останавливаться на этом 😆😆😆
А не остановившись, что же добавлять дальше?
Этап "принятие". Видимо ощутили, как от плюсовиков денежки утекаю, вот и начали суетиться и воровать хорошие идеи. Безопаснее кресты конечно же не станут, а вот повыступать на конференциях и пособирать донаты на этом ужасе - благое дело.
Таким как ты не угодишь. Не тащат в С++ фичи Раста - плохо. Тащат - тоже плохо.
> Не тащат в С++ фичи Раста - плохо.Кто сказал что плохо? Те самые, которые кричали "ненужОн нам ваш раст с его боровом, нам и с++ хватит!" ?
Или это другие?))> Тащат - тоже плохо.
Наоборот хорошо! До них наконец-то стало доходить!
Ну вот теперь C++ действительно хватит, непонятно чем ты недоволен ))
Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет.
> Принятия что все будет в плюсах и ни в каком расте нет необходимости?А когда будет?
В 26 стандарт уже не попадает, в 29й тоже сомнительно.
Т.е возможно, если они договорятся в 32-35 году на плюсовиком снизойдет благодать.> Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет.
Странно, раньше талдычили что "раст не нужон! боров ваш тоже не нужон!! смартпойнтеров всем хватит!".
А тут целый президент C++ Alliance говорит "там классные идеи".
Вот это переобувание в прыжке))
Так в нынешнем стандарте и ненужен. А в будущем может ещё телепатию в стандарт примут кто знает.
> А тут целый президент C++ Alliance говорит "там классные идеи".
> Вот это переобувание в прыжке))Так это засланный казачок от проклятых корпораций коварно пускает метастазы раковой опухоли в чистый, свободный, независимый сад C++ 😂
> Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет.Только вот в Расте это все уже есть здесь и сейчас. А в плюсах нет и не будет ближайшие лет 10 точно.
Талдычте дальше...
Трехтысячный раз лично тебе повторяю.Раст это отсутствие совместимости между версиями и полное отсутствие бекпортировпния фиксов в старые версии. Ужасный синтаксис переполненный спецсимволы и ужасное комьюнити. Поэтому раст не может взлететь как концепция.
Борова почекать можно в с++ прям сейчас. Умные указатели нет ничего проще. Добавить новую спецификацию в будущем почему бы и нет.
Как скажешь.
> Борова почекать можно в с++ прям сейчас. Умные указатели нет ничего проще.Oh my sweet summer child...
Я смотрю, чем меньше эксперт шарит в C++ и Rust, тем сильнее у него "нет ничего проще" и "Rust не нужен".
Чекер борова просто при существовании алиаса для ссылки запрещает мутации. Чем ужасно всех бесит даже адептов раста. И пишется кем угодно левой ногой настолько он приметивен.
> Чекер борова просто при существовании алиаса для ссылки запрещает мутации.Так может в этом есть какой-то смысл? Или для всего непонятного у тебя есть одно универсальное объяснение, что авторы - дураки?
> И пишется кем угодно левой ногой настолько он приметивен.
Молодец: ты еще раз подтвердил утверждение выше "чем меньше эксперт шарит в C++ и Rust, тем сильнее у него "нет ничего проще".
>Раст это отсутствие совместимости между версиямиhttps://doc.rust-lang.org/edition-guide/introduction.html
>Ужасный синтаксис переполненный спецсимволыВзяли худшее от семейства си. Кресты так же уродливы, со своими cout << "123"; T<A> a; [&, i]{}; [=, *this]{ };
В С++ у тебя есть выбор писать коряво спецсимволами либо в нормальный синтаксис. В расте этой возможности много где нет.
Не будет ли любезен многоуважаемый джинн привести небольшой пример кода на 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,
}
}
//-----------------------------------------------------------
}
//-------------------------------------------------------------------
> В С++
> нормальный синтаксисТы же шутишь, да?
Что из этого необычный синтаксис плюсов?
А писать несколько операторов в одну строчку - это неизлечимая болезнь в мозгу недопрограммиста.
Не надо пороть чушь - ей больно. Написанное вами показывает, что в предмете вы не разбираетесь от слова совсем и язык Rust просто не осилили.
> Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычимО какое виртуозное переобувание в воздухе. Лицемеры. Вы который год уже талдычите, что Настоящему Погроммисту все эти ваши боровы чекеры и битиЕ компилятором линейкой по рукам не нужно, ибо Он, Богоподобный Погроммист, сам всё знает и умеет, и, главное, НЕ ОШИБАЕТСЯ (а кто ошибается, те не настоящие и гнать их в дворники). А тут такое.
Вы хотели чекер борова - вам дают чекер борова в C++. Но внезапно это оказывается - "воровать хорошие идеи". И он еще что-то говорит про лицемерие.
> Вы хотели чекер бороваНет, мы хотели чтобы перестали писать на дыряшке/плюсах, и писали на расте.
> Но внезапно это оказывается - "воровать хорошие идеи".
поэтому никакого противоречия.
> И он еще что-то говорит про лицемерие.
Именно. Это именно лицемерие. Когда годами вы говорили "ненужОн нам ваш боров, нам и так нормально!", а потом такие "хотя... подождите!"
> Вы хотели чекер борова - вам дают чекер борова в C++. Но внезапно это оказывается - "воровать хорошие идеи"Термин "воровать" человек применил в сердцах, от раздражения на вашу флюгерность. Да воруйте (или как хотите называйте) на здоровье! Бог в помощь! Вот только сначала долгое время кричать, что эти идеи "плохие", а потом их "воровать", соглашаясь, что они "хорошие" - вот это верх лицемерия и переобувания. Теперь объясни, когда вы были правы - тогда или сейчас, каким вашим словам верить? П - Последовательность.
П.С. Можешь не отвечать, после такой последовательности в убеждениях Ваше мнение (не) ценно для нас.
А кто кричал, что идеи плохие? Воображаемые растохейтеры в твоей голове?
Идеи хорошие, но сам Rust недостаточно хорош для перехода на него. Что тут непонятного и непоследовательного в этой позиции?P.S. Можешь не отвечать, все равно фанатики Rust ничего нового не напишут кроме своих стандартных агиток.
> воровать хорошие идеиКакое слово нехорошее подобрал, явно специально. Раст, конечно, все изобрел с нуля.
Многие идеи перекачевывают из проекта в проект. Что в этом плохого?
> Видимо ощутили, как от плюсовиков денежки утекают, вот и начали суетиться и воровать хорошие идеи.Не пишешь на плюсах, вот и бесишься!
Оригинал всегда лучше копии!
Да Пёрл лучше всех.
Нишевый язык. Можно сказать, DSL.
У нас вестник из будущего, ловите!
Спали, спали, зачем проснулись? Итак, какие минусы у данного решения? Ошибки, в частности ошибка на миллиард долларов(наличие null) из плюсов никуда не денется. Существующие проекты, если и будут переписываться, то всё это будет крайне медленно. Понять, переписан уже какой-то проект или нет будет крайне затруднительно, особенно для тех, кто не знаком именно с плюсами. Часть проектов будут сочетать в себе безопасные и небезопасные части, при этом любой коммит будет менять их в произвольные стороны. Это не раст, в котором нужно оборачивать код в unsafe. Время компиляции: в плюсах есть десятки разных способов затормозить компиляцию, начиная с возможности инклюдить произовльные файлы в произвольные места, в том числе с возможностью циклических зависимостей(аналогичная проблема в си), продолжая всякими шаблонами и прочим. Судя по всему, коммитет это не волнует. Код хромиума уже может собираться больше суток на среднем ноутбуке, упираясь как в количество ядер, так и в количество оперативки, без возможности как-то это ускорить. Стандарт плюсов уже огромен, со всем этим он станет ещё больше. И самое главное: появление этих возможностей никак не заставит разработчиков им следовать. Некоторые пишут на си с классами, теряя часть гарантий плюсов, типа умных указателей. Так что закапывайте уже плюсы. Хотите - создавайте новый язык, хотите, развивайте любой существующий. Посмотрите на фичи других языков, типа зависимых типов в ATS.
> Код хромиума уже может собираться больше суток на среднем ноутбуке, упираясь как в количество ядер, так и в количество оперативки, без возможности как-то это ускорить.На расте он быстрее будет собираться что-ли?
> типа зависимых типов
И зачем они если тебе не нужны доказательства?
>На расте он быстрее будет собираться что-ли?А при чём тут раст? Я писал про то, какой монстр плюсы
>если тебе не нужны доказательстваС чезо вдруг тагие утверждения?
>С чего вдруг такие утерждения?
Потому что одна из основных задач для завтипов — это различные пруверы типа Идриса и кока. Если нет, то приведи пример зачем нужны завтипы для бытового программирования. Возможность взять голову пустого списка и получить ошибку не принимается.
>Возможность взять голову пустого списка и получить ошибку не принимается.Почему это? Вы предпочитаете попортить память/упасть?
Типизация поможет в том чиле и против утечек памяти и против двойного освобождения.
>>Возможность взять голову пустого списка и получить ошибку не принимается.
> Почему это? Вы предпочитаете попортить память/упасть?На мой взгляд это не токое важное место, чтобы так сильно усложнять систему типов.
> Типизация поможет в том чиле и против утечек памяти и против двойного
> освобождения.Завтипы? Можно подробнее в этом месте? Вроде же idris, coq, lean все с gc.
>На мой взгляд это не токое важное место, чтобы так сильно усложнять систему типов.Ими пользуются по необходимости
>Завтипы? Можно подробнее в этом месте?Посмотри на ATS - язык с линейными и зависимыми типами, по умолчанию без GC, правда он скорее экспериментальный, чем практический.
> Стандарт плюсов уже огромен, со всем этим он станет ещё больше.А зачем тебя это так волнует? Вон в расте стандарта никакого нет, каждый релиз новую порцию апи публичат (и не малую).
>А зачем тебя это так волнует?Вопрос возможности чтения кода посторонними людьми и понимания самим автором. А то с этим частенько бывают проблемы, когда автор сам не понимает, как должен работать его код
>новую порцию апи публичатЕсть огромная разница между добавлением новой семантики и новым апи. При добавлении апи, язык остаётся тем же, порой даже это можн о было бы реализовать и в старой версии, ну а с новым апи нужно в корне менять подход
> Вопрос возможности чтения кода посторонними людьми и понимания самим автором. А то с этим частенько бывают проблемы, когда автор сам не понимает, как должен работать его кодТы сейчас на серьезных щах утверждаешь, что все кто пишут на расте все понимают? И знают ллвм?
Чтобы писать на с++ не надо досконально знать стандарт, да и кроме комитетчиков его реально мало кто знает.
>Чтобы писать на с++ не надо досконально знать стандарт,Я не пишу ни на c ни на c++. Однако, читая код на этих языках, регулярно вижу отсутствие понимания происходящего типа такого https://github.com/ProfessorNavigator/mylibrary/blob/b249bf8... https://habr.com/ru/articles/522208/
И я крайне сомневаюсь, что те, кто не осилили парсер не побьют память, ведь их общийуровень понимания крайне низок
>>Чтобы писать на с++ не надо досконально знать стандарт,
> Я не пишу ни на c ни на c++. Однако, читая код
> на этих языках, регулярно вижу отсутствие понимания происходящего типа такого https://github.com/ProfessorNavigator/mylibrary/blob/b249bf8...
> https://habr.com/ru/articles/522208/Можно обернуть данный код в с++ в класс, в котором надо проверять ошибку типа absl::Status, outcome::result, Boost::Outcome или std::expected из с++23. Просто это разный подход к обработке ошибок.
> И я крайне сомневаюсь, что те, кто не осилили парсер не побьют
> память, ведь их общийуровень понимания крайне низокЕсть готовые библиотеки для разбора. Если человек не читает документацию, то проблема сильно ниже.
>Можно обернуть данный код в с++ в классДля этого, нужно как минимум подозревать о проблеме. В плюсах компилятор никак не подскажет, что здесь что-то не то.
> И я крайне сомневаюсь, что те, кто не осилили парсер не побьют память, ведь их общийуровень понимания крайне низокОпять вы со своей чушью. Так и будете таскать свои глупости из поста в пост, в надежде, что никто не будет вникать? Ну-ну, продолжайте... Посмотрим, чем это закончится.
>в надежде, что никто не будет вникатьКак вижу, вы до сих пор не поняли в чём проблема, и не поправили парсер
> Как вижу, вы до сих пор не поняли в чём проблема, и
> не поправили парсерНу так расскажите)) А то я от вас ничего, кроме всякого бреда, пока что-то не видел. Про производительность, если что, можете сказки сразу не рассказывать - тестировалось это всё на 500+ Гб файлов, результат - вполне удовлетворительный. Утечек памяти нет, ошибок - тоже. По крайней мере с февраля жалоб не поступало. У меня у самого нареканий тоже нет. Со скоростью работы там есть проблемы, но отнюдь не в парсере, а в той части, что работает с архивами. Вот там - да, есть ещё над чем поработать. Да и дело то не в этом. Я тоже человек, вполне могу ошибиться - мои программы не истина в последней инстанции. Дело в том, что вы тут проповедуете, какими методами и для чего. Как иллюстрация - вторая ссылка, которую вы тут из поста в пост таскаете. Повторю ещё раз - там проблема банальна и проста. Функция в случае ошибки возвращает -1. И если вы не проверите на минус единицу, то естественно у вас будут проблемы. В программировании оно везде так - любая мелочь имеет значение, потому что любой символ - это вполне определённые машинные инструкции.
>Про производительность, если что, можете сказки сразу не рассказывать - тестировалось это всё на 500+ Гб файлов, результат - вполне удовлетворительныйУдовлетворительный результат - это понятие весьма растяжимое.
>Утечек памяти нет, ошибок - тоже. По крайней мере с февраля жалоб не поступалоЯ не будут перечислять все проблемы заново, но ещё раз повторюсь, у вас нет совместимости со всей семантикой xml. Банально код <tag attr1="attr3" attr2="val1" attr3="val2"/> ваш парсер не сможет разобрать. И подобных примеров, когда ваш парсер будет работать неправильно - куча. Если вам повезло, и подобные строки не встретились, это всё ещё не говорит, о том, что ваш парсер работает нормально
>В программировании оно везде такКак раз для таких случаев и придумали алгебраические типы данных, если уж исключения бросать не хочется. Там не получится случайно передать ошибку в другую функцию - только намеренно.
> Удовлетворительный результат - это понятие весьма растяжимое.Нет, не растяжимое. Задача была - создать программу, которая будет собирать базу данных из различных типов электронных книг и архивов любой глубины. Вторая задача - организовать поиск по этой базе данных по определённым критериям и открытие найденных файлов. Именно это программа и делает. Это называется "удовлетворительный результат". Хорошим он станет, когда удастся избежать крахов на 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. И возвращаемое значение нужно проверять, иначе ничего хорошего не получится. Хоть с алгебраическими типами данных, хоть без них.
>Алгебраические типы данных придумали для того, чтобы работать с большими числами в первую очередьЧто? У вас какое-то своё собственное понимание данного термина. Алгебраические типы данных, это например
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 их кидает.
>Хоть с алгебраическими типами данных, хоть без них.Хорошо, с парсером разобрались, что такое алгебраические типы данных я вам объяснил, что ещё вы понимаете не так?
> Что? У вас какое-то своё собственное понимание данного термина. Алгебраические типы данных,
> это например
> 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 может быть как угодно прекрасен (что в реальности, мягко говоря, не так), но пока за ним стоят барыги - нет, нет и нет.
> Да, каюсь - не посмотрел значение термина сначала. Теперь выяснил.И не в первый раз вы с умным видом рассуждаете про вещи, о которых почти ничего не знаете.
> И всё оказалось ещё большей чушью, чем я думал. Как говорится - поздравляю.
Спасибо за поздравление)
Через сколько комментов будет очередное "я не почитал что оно значит"?> Вы заново изобрели те же классы С++. Осталось выяснить - зачем?
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 - это те же самые "барыги".
Так что выкидывайте с++ на помойку и пользуйтесь православным ДРАКОНон или КуМиром.
> И не в первый раз вы с умным видом рассуждаете про вещи,
> о которых почти ничего не знаете.Да-да, я ничего не знаю, конечно)) Но, проблема, повторюсь не в моём знании или незнании, а в том, что всё, что вы пишите про преимущества 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 под себя. Впрочем, есть неплохой шанс, что они таки поссорятся на этой теме. Но вряд ли успеют. Потому что в самом ближайшем будущем никаких корпораций вообще не останется. По одной из двух причин: будет революция или все сдохнут. Выбирайте, что вам больше нравится.
> Да-да, я ничего не знаю, конечно))Подмена понятий это не очень красивая манипуляция. Приравнивание "почти ничего" и "ничего".
> вы пишите про преимущества 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 назад.
И закончилось все голодом, мировыми войнами, геноцидами и прочим.
Спасибо не надо.
>> До изобретения СИшки было еще два года, до появления плюсов - больше
>> десятка лет...
>И что?))А то, что нормальные языки появились давным давно, но были затмены говнокодом. И если си ещё мог с ними соревноваться, так как он ровесник некоторых из них, то вот уже c++ или python - появились после них, и уже на момент своего релиза отставали по фичам. Про голанг и говорить не приходится
>Вам нормальным языком говорят: про проблемы мы в курсеА точно в курсе? Вы давненько уже опубликовали свою программу, кто-то ваш код читал и про парсер вам писал? Другие части ревьювил? Увы, но далеко не у каждого сишника/плюсовика есть человек, который объяснит ему что и почему он сделал неправильно.
>Самоучка - да. В плане программирования. Без университетского образования - даУчитывая то, какие в некоторых ВУЗ-ах программы, то диплом тоже ничего не гарантирует. Если это не МГУ какое-нибудь.
> А то, что нормальные языки появились давным давно, но были затмены говнокодом.О да)
СИшка это ПХП из 70х, чтобы любой б-ло кодер мог забацать какой-то код, и если ему удача повернется лицом, даже переносимый.Можно вспомнить как разрабатывалась АДА.
Сначала они 2 года и 5 итераций собирали требования.
Потом они устроили конкурс на разработку нового языка и 5 лет он был написан.
Потом они запретили выпускать компиляторы, которые не прошли пакет тестов (больше тысячи).
Хотя бы один тест провалился - всё, ты идешь лесом.Если вспомнить как рождался СИ и его стандарт (на который тая неистово фапают фанатики), то это десятки не совместимых друг с другом компиляторов, куча противоречий в стиле "ХЗ чо тут делать, компилятор сам разберется" и как вишенка на торте и овна - стандарт не обязателен к выполнению.
Отрываешь C compiler support
en.cppreference.com/w/c/compiler_support смотришь на красные пятна неподдерживаемых фич и думаешь, а почему это овно вообще называется "компилятор С"?И с плюсами история почти такая же. С теми же последствиями.
en.cppreference.com/w/cpp/compiler_supportНо, история не имеет сослагательного наклонения, и быд-о код победил.
Язык для которого уровень квалификации пограммиста нужен был "бибизяна умеет жать на клавиши" распространился в очень важные проекты.
> А то, что нормальные языки появились давным давно, но были затмены говнокодом.
> И если си ещё мог с ними соревноваться, так как он
> ровесник некоторых из них, то вот уже c++ или python -
> появились после них, и уже на момент своего релиза отставали по
> фичам. Про голанг и говорить не приходитсяНу т.е. опять безосновательный наброс. Какие "фичи", вы о чём вообще? У вас на С++ стандартная библиотека такого размера, что её ни один программист целиком не знает (да и не нужно это - нормальные люди перед реализацией интересуются наличием необходимых инструментов). Плюсом к этому в С++ вы вполне можете использовать примерно 99% кода из С напрямую. Если не хватает и этого - вам сделали ассемблерные вставки: делайте, что хотите.
> А точно в курсе? Вы давненько уже опубликовали свою программу, кто-то ваш
> код читал и про парсер вам писал? Другие части ревьювил? Увы,
> но далеко не у каждого сишника/плюсовика есть человек, который объяснит ему
> что и почему он сделал неправильно.Прикрутите фонтан самомнения, иначе мне придётся вам в грубой форме пояснить, куда вам следует сходить. А мне бы этого не хотелось - здесь детей много.
> Учитывая то, какие в некоторых ВУЗ-ах программы, то диплом тоже ничего не
> гарантирует. Если это не МГУ какое-нибудь.Хы)) Я таких выпускников МГУ видал, что их на пушечный выстрел вообще ни к чему подпускать нельзя. Это я к том, что ВУЗ - да, не показатель. А вот профессия - по обстоятельствам. В моей (теперь уже бывшей), если вы не будете нормально применять знания, то всё закончится или вашей смертью, или тюрьмой. Я пока жив и даже на свободе, так что, видимо, образование у меня неплохое))
>Какие "фичи", вы о чём вообще?Например, алгебраические типы данных. Никаким размером стандартной библиотеки их отстутствие не компенсировать
>Плюсом к этому в С++ вы вполне можете использовать примерно 99% кода из С напрямуюВ какой-то момент хочется не количества, а качества
>Прикрутите фонтан самомнения, иначе мне придётся вам в грубой форме пояснить, куда вам следует сходить.Самомнение здесь только у вас, раз на обоснованную критику вы готовы посылать в грубой форме
>Да, каюсь - не посмотрел значение термина сначала. Теперь выяснил. И всё оказалось ещё большей чушью, чем я думалХорошо, что вы не закостенелив в своём незнании
>Вы заново изобрели те же классы С++Алгебраические типы данных решают схожую, но всё же отличающуюся задачу. Решение через классы будет гораздо многословнее, но проблема даже не в многословности. Проблема в том, чтобы убедить плюсовиков преодолеть "парадокс блаба"(да, по этому поводу есть хорошая статья).
>Ну и на кой изобретать вот это вот всё, когда достаточно банального 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++. Когда я понимаю, как легко создать баг на си/плюсах, у меня отпадает малейшее желание писать хоть самый маленький патч для этих программ.
> Хорошо, что вы не закостенелив в своём незнанииЧего-то не знать не стыдно. Стыдно не стремиться расширять свой кругозор.
> Алгебраические типы данных решают схожую, но всё же отличающуюся задачу. Решение через
> классы будет гораздо многословнее, но проблема даже не в многословности. Проблема
> в том, чтобы убедить плюсовиков преодолеть "парадокс блаба"(да, по этому поводу
> есть хорошая статья).А зачем собственно? Не устраивает - пишите на том языке, на котором вам удобно. Зачем плюсовиков в чём-то убеждать? Они ж по большей части в геймдеве заняты. А эта область - далеко не весь 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++. Когда я понимаю, как легко создать баг
> на си/плюсах, у меня отпадает малейшее желание писать хоть самый маленький
> патч для этих программ.Ну так и не пишите, и не пользуйтесь "говнокодом" - вас насильно никто не заставляет.
>Зачем плюсовиков в чём-то убеждать? Они ж по большей части в геймдеве занятыУвы, но нет. Огромное количество софта написано на си/плюсах. 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 это вообще системный язык(с вытекающей отсюда производительностью и низкоуровневостью).
>Ну так и не пишите, и не пользуйтесьУвы, но я не могу писать абсолютно весь софт для себя сам. Вот не смогу я написать, например видеоредактор для того, чтобы однократно видео обрезать.
> Увы, но нет. Огромное количество софта написано на си/плюсах. 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 в целом. Решать же проблему предлагается... встраиванием статического анализатора кода в компилятор. И зачем? Если можно просто написать нормальный статический анализатор кода для тех же С/С++? В общем лучше, как уже написал выше, смиритесь и потратьте время на что-то более полезное, чем на споры со мной.
> Увы, но я не могу писать абсолютно весь софт для себя сам.
> Вот не смогу я написать, например видеоредактор для того, чтобы однократно
> видео обрезать.Не нужно ничего писать. Просто бросьте ф...ней страдать, и внезапно всё наладится. У вас проблемы есть куда как посерьёзнее, чем бессмысленные споры о ненужных ЯП - вот-вот мировая война очередная начнётся. А может даже и уже идёт.
> Дело не в нежелании, а в возможностях. Вы уверены, что на каком-нибудь микроконтроллере у вас будет достаточно ресурсов? А системы реального времени?Нет конечно.
Но речь идет о ядре линукс или вообще о телефонах с андроидом.
Для микроконтроллеров и тем более RTOS подходы совершенно другие.> Где критически важно время обработки того или иного сигнала, а ошибки - можно и потом обработать. Например проверив - отработал ли процесс.
Прям как сделали разработчики Therac-25 убившие кучу народу.
Или просто перезагрузив весь контроллер, как сделали Тойотовцы, и тоже с человеческими жертвами.> В общем - не нужен Rust, не нужен. Смиритесь уже))
Вы видели мемное видео про "не нужон ваш интернет!"? Оно мне чего-то вспомнилось)
> И лучше своё время потратьте на что-нибудь более полезное, чем бесполезные комментарии на форумах.
Комментарии полезные.
Придует такой зеленый программист, студент или даже школьник.
Почитает какое дно языки прошлого столетия и возможно не будет вкладывать в них усилия.
Это же просто забота о нашем будущем!> Да без проблем. Дело в другом - он просто не нужен. Он возник, потому что несколько "не таких, как все" чисто по приколу решили написать свой язык.
Примерно как Страуструп расширял СИшку? И потом выкатил си++?
Вы не слышали как появилась QNX?
Пара студентов после базового(!!) курса "как разработать ОС" решили попробовать. И у них получилось!
А еще можно взять в пример одного матюкающегося фина, который решил "буду не такой как все! запилю свое ядро".> А корпорации в нём увидели способ нажиться - и понеслась.
Хм.. и как они на нем наживаются?
> С технической точки зрения оно бесполезно от слова совсем, поскольку создаёт ненужные проблемы на ровном месте, а вот преимущества - весьма сомнительные.
Не уверен что моих или ваших компетенций достаточно, чтобы оценить техническую точку зрения.
> Rust и прочие подобные ЯП пытаются решить ровно одну проблему: падение уровня квалификации программистов.
О, начинается)) "раньше програмитсы быљи огого, а сейчас... И код был оггого! Не то что сейчас"
Можно просто написать в поиске этого сайта "уязвимость" и посмотреть как "качественно" писали раньше.> Решать же проблему предлагается... встраиванием статического анализатора кода в компилятор. И зачем? Если можно просто написать нормальный статический анализатор кода для тех же С/С++?
Но за пол века его никто не написал.
Наверное никому не нужно.> У вас проблемы есть куда как посерьёзнее, чем бессмысленные споры о ненужных ЯП - вот-вот мировая война очередная начнётся. А может даже и уже идёт.
Т.е если где-то идет война, можно работу делать тяп-ляп?
А может я уже на войне и мне нужен надежный ЯП, программу на котором не смогут взломать "написав" 28 бекспесов?
Давайте так. Я вам отвечу, но при одном условии - вы честно скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку. В противном случае - общайтесь с зеркалом. Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно.
> Давайте так. Я вам отвечу, но при одном условииДа вы не утруждайтесь вы так.
Зачем тратить время на каких-то анонимов.> - вы честно скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку.
Предложение конечно интересное, но ответу "мне не платят, я просто весело провожу время" вы наверняка не поверите.
И это ваше полное право.> В противном случае - общайтесь с зеркалом. Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно.
Так ответов особо и не было.
Были какие-то бездоказательные утверждения про "не нужно", "маркетинг", "получают выгоду", "ничем не лучше".
Которые как чайник рассела - ни опровергнуть, ни подтвердить.
Причем они пихаются как аксиомы.
>Я вам отвечу, но при одном условии - вы честно скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку.Рыцарь на белом коне, вы Дон Кихот. Достаточно просто почитать спецификации си/плюсов, чтобы было понятно какой это ужас. Если вы недостаточно компетентны, то пойдите, почитайте, например блог PSV-Studio, разработавший статический анализатор для данных языков.
>Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно.Вы не обсуждаете, вы строите свои догадки, и блуждаете в плену иллюзий. Я вам несколько раз писал про алгебраические типы, но вы не удосужились прочитать, что это, и высказали своё неприятие. Только после того, как я привёл вам пример, вы признались в собственном незнании. Теперь вы придумали, что ADT реализуются как классы, с алокацией памяти в куче. Далее, будет идти вопрос о том, зачем нужен тип Option, когда есть null, но вы настолько застряли в "парадоксе Блаба", что отвергаете всё вам непонятное.
>Спасибо, но вот go - точно не надо.Уж лучше уж go, чем си/плюсы, там хоть программистов муштруют GC, и постоянными err != nil. Авось, go-шник, уставший после каждой строки писать err != nil оценит красоту того же Ocaml.
>Дело не в нежелании, а в возможностях. Вы уверены, что на каком-нибудь микроконтроллере у вас будет достаточно ресурсов?С какого момента речь зашла о микроконтроллерах? Почему при программировании десктопного/серверного софта меня должны волновать микроконтроллеры?
>Во-вторых, опять же там, где достаточно банального int размером 16-32 бита, вы предлагаете запихнуть целый классВо-первых, шестнадцатиразрядные ОС уже давно ушли в историю. Во-вторых, вы упорно повторяете свою же придуманную идею про классы. Вы так и не почитали, как это под капотом устроено, а устроено оно достаточно эффективно.
>Более того, если уж так зачесалось - то на С++Вот самая большая проблема - убедить плюсовика в том, что портить память, спотыкаться на UB, жонглировать магическими константами, велосипедить прочие вещи - неправильно. Вы мне сейчас предлагаете всю стандартную библитеку переделывать, когда в том же Ocaml всё это уже есть из коробки
>И лучше своё время потратьте на что-нибудь более полезное, чем бесполезные комментарии на форумах.На любом форуме нужно предупреждать новичков о существовании хороших языков, типа Ocaml, и языков для отстрела ног, типа си или плюсов.
>Смотрите код, как обрабатываются атрибуты.Вы мне не поверите до тех пор, пока я вам не скину файл, который будет неправильно обрабатываться вашей программой?
>Ну во-первых, она на С, а не на С++.И что? Найдите на плюсах, несколько минут поиска.
>Но это не суть важно. Важно другое: как и писал выше - зачем?Вам не нужна корректная обработка xml? У вас плохо работает почти всё: и распознавание атрибутов, и значение этих атрибутов и так далее. Или вам нужно буквально скинуть файл, который ваша программа не распознает? Мне лень править файл.
>А не ковыряться в незнакомом API, разбираясь, как его подогнать под выполняемые программой задачи.Я был о вас лучшего мнения. Вот что-что, а взять библитеку, и разобрать с её помощью xml - это гораздо проще, чем реализовывать парсер с нуля
>Rust и прочие подобные ЯП пытаются решить ровно одну проблему: падение уровня квалификации программистов.А вы сами - квалифицированный программист? Ещё раз повторюсь, если вашей библитеке подать на вход специально созданный под неё xml, то она не сможет его правильно разобрать.
> Есть огромная разница между добавлением новой семантики и новым апи.И где кроме 11 стандарта как-то в корне меняли семантику?
Ты не переживай, раст это не про стабильность компилятора, там семантику сменят и узнаешь об этом по сломаной сборке.
>И где кроме 11 стандарта как-то в корне меняли семантику?А зачем её менять в корне? Достаточно добавить каких нибудь модулей
>>И где кроме 11 стандарта как-то в корне меняли семантику?
> А зачем её менять в корне? Достаточно добавить каких нибудь модулейИ в чем проблема? Ну ты реально пытаешься, что-то доказать, но сам кажется до конца не понимаешь что именно.
>И в чем проблема?Проблема в понимании c++ кода. Огромное количество фич, и у каждой фичи есть свои особенности. Возможно, новые способы отстрелить ногу.
> Некоторые пишут на си с классами, теряя часть гарантий плюсов, типа умных указателей.Ну Кармак так id tech 4 написал, а растоманы за 14 лет не шмогли. Может дело в чем-то другом?
> Время компиляции: в плюсах есть десятки разных способов затормозить компиляцию, начиная с возможности инклюдить произовльные файлы в произвольные местаТо есть ты предлагаешь СПЕЦИАЛЬНО делать ерунду и говорить что все плохо?
>СПЕЦИАЛЬНО делать ерундуВо-первых, хорошие языки ерунду не компилируют, а пишут ошибку. Во-вторых, я крайне сомневаюсь, что в команде хромиума сидит злодей и внедряет пакости. Просто компилятор плюсов тормозит из-за сложности последних
Нужно переписать весь хромитам на раст и померить время сборки на холодную. А без этого твои слова ничем не доказуемы. У них много кода, вот он долго и компилится первый раз. К слову в расте раньше не было инкрементальной сборки и Дропбокс плакался по этому поводу достаточно сильно.
>Нужно переписать весь хромитам на растУ вас болезненная зацикленность на расте?
>А без этого твои слова ничем не доказуемы.Вы не видите очевидных доказательств. Вот один из примеров https://www.opennet.me/opennews/art.shtml?num=56475
>У них много кода, вот он долго и компилится первый раз.Нет, это сишники не осилили нормальный компилятор. Запрети циклические зависимости, и проблема выше решится сама собой, без необходимости строчить огромные патчи. А даже если патч примут, то снова разведут бардак.
Зато сишники освоили более одного production-ready компилятора, и все благодаря наличию стандарта.
>>Нужно переписать весь хромитам на раст
> У вас болезненная зацикленность на расте?Критикуя, предлагай. с++ единственный вариант для хромиума. Кода много, поэтому и компилится долго. Просто это овердофига большой проект. Возможная замена - это раст. Но как сильно изменится время компиляции? Попробуй собери что ли компилятор раста или firefox и сравни.
>>А без этого твои слова ничем не доказуемы.
> Вы не видите очевидных доказательств. Вот один из примеров https://www.opennet.me/opennews/art.shtml?num=56475Нашел новые?) Могу еще подсказать поискать новости про то, что в ядре повторяется куча кода в разных подсистемах.
>>У них много кода, вот он долго и компилится первый раз.
> Нет, это сишники не осилили нормальный компилятор. Запрети циклические зависимости, и проблема
> выше решится сама собой, без необходимости строчить огромные патчи.Ну ты же не пишешь на си и с++ как ты говоришь. Почему ты судишь осили кто-то или нет?
> А даже если патч примут, то снова разведут бардак.
Попробуй посопровождай проект подобного уровня и посмотрим какой там будет бардак. Чел, это не бардак)
>Кода много, поэтому и компилится долгоВы ссылку читали?
>При использовании Clang применение патчей позволило сократить время сборки на 88% или на 77%Функционал остался тем же, но собираться стал более чем в четыре раза быстрее
>Критикуя, предлагайЯ ясно сказал, что нужно сделать: запретить циклические зависимости, хотя бы на уровне линтера. Вот вам Ocaml https://wiki.xenproject.org/wiki/OCaml_Cyclical_Build_Depend... Слышал, что в делфи аналогично, но утверждать не берусь.
>Почему ты судишь осили кто-то или нет?Потому, что когда я создал подобную проблему в Ocaml, в гораздо меньшем масштабе, то компилятор меня сразу же предупредил. При работе с Ocaml периодически чувствуешь, как компилятор активно мешает писать плохой код, в то же время, когда я собирал си/плюсы, то компиялторы собирали абсолютно любой синтаксически корректный говнокод.
>Чел, это не бардак)Вот в этом то и проблема. Сишники/крестовики будут отказываться признавать наличие проблемы. Ну и что, что время компиляции растягивается, типичный сишник и не знает, что компиляция может быть быстрой.
> При работе с Ocaml периодически чувствуешь, как компилятор активно мешает писать плохой код, в то же время, когда я собирал си/плюсы, то компиялторы собирали абсолютно любой синтаксически корректный говнокод.Зачем сравнивать функциональный язык с GC и императивный без GC? Блин, да для ocaml даже нормальной gui библиотеки нет. Ну что-то браузера на ocaml не видел, хотя вот на common lisp есть.
>Зачем сравнивать функциональный язык с GC и императивный без GC?А какая разница? Почему нельзя запретить циклические ссылки на исходники в империативном языке?
> Вот в этом то и проблема. Сишники/крестовики будут отказываться признавать наличие проблемы.
> Ну и что, что время компиляции растягивается, типичный сишник и не
> знает, что компиляция может быть быстрой.Никто не отказывается ничего признавать. Ее решают по другому просто. Я тебе еще раз говорю: возьми свой любимый яп, возьми проект уровня хромиума (по кол-ву кода) и покажи мне время сборки для него. Ну только чтобы без рантайма яп был.
>Ее решают по другому простоКак решают? Периодически патчи присылают, как с linux? Это не решение проблемы языка, это исправление одного единственного проекта. Для freebsd нужно будет начинать с нуля.
>возьми проект уровня хромиума (по кол-ву кода) и покажи мне время сборки для негоВопрос не в количестве строк как таковых(тут да, chromium - рекордсмен). Вопрос в том, что существуют короткие примеры, порой меньше сотни строк, которые растягивают время компиляции в несколько раз, а то и на несколько порядков. К сожалению не могу найти статью про c++, вот пример со swift https://habr.com/ru/articles/283106/
>Ну только чтобы без рантайма яп был.У плюсов есть рантайм.
>>Ее решают по другому просто
> Как решают? Периодически патчи присылают, как с linux? Это не решение проблемы
> языка, это исправление одного единственного проекта. Для freebsd нужно будет начинать
> с нуля.Кэш, распределенная сборка.
>КэшЯ не помню точных цифр, но вместе с кешем хромиум собирался не больше суток, а часов за шесть, что всё равно много.
>>Кэш
> Я не помню точных цифр, но вместе с кешем хромиум собирался не
> больше суток, а часов за шесть, что всё равно много.Поэтому в гугле используют распределенную сборку. Написал же. Ну и не только там если что.
Нашёл пример для плюсов https://habr.com/ru/companies/jugru/articles/438260/
>Время компиляции этого реально наипростейшего примера заняло на 2.85 секунды дольше, чем версия с «простым C++».
>Например, за какое время clang сможет скомпилировать настоящий полноценный движок базы данных (SQLite) в отладочном режиме, включая все 220 тысяч строчек кода? За 0.9 секунд на моём ноутбуке.
> Нашёл пример для плюсов https://habr.com/ru/companies/jugru/articles/438260/
>>Время компиляции этого реально наипростейшего примера заняло на 2.85 секунды дольше, чем версия с «простым C++».
>>Например, за какое время clang сможет скомпилировать настоящий полноценный движок базы данных (SQLite) в отладочном режиме, включая все 220 тысяч строчек кода? За 0.9 секунд на моём ноутбуке.Ой, там сравнивают с c#. Как говорится в одной известной цитате из собачьего сердца "поменьше читайте газет"
> это сишники не осилили нормальный компиляторДля си есть верифицированный компилятор https://compcert.org/, компиляторы попроще tcc (используется для бутстрапинга) и куча других проектов. Так что тут не прав. Выбор - это всегда хорошо.
> Часть проектов будут сочетать в себе безопасные и небезопасные части, при этом любой коммит будет менять их в произвольные стороныУ нормальных проектов есть различные чекеры (тот же clang-tidy, который можно настроить на следование различныи фичам) и ревью. А проблема, которую ты описываешь - это общая проблема всех развивающихся во времени систем.
>У нормальных проектов есть различные чекерыВот вы и назвали важный недостаток. Нужно, чтобы повезло и в проекте оказался анализатор, чтобы договорились включить диагностику, чтобы если диагностика выдаст пару сотен тысяч ошибок её не отключили, чтобы библиотеки тоже проверялись и так далее. И редко, когда всё совпадает. Вот когда анализатор встроен в язык, тогда всё работает из коробки. В реальности же целый гугл не смог реализовать парсер json, и им пришлось брать его из раста
> Вот вы и назвали важный недостаток. Нужно, чтобы повезло и в проекте оказался анализатор, чтобы договорились включить диагностику, чтобы если диагностика выдаст пару сотен тысяч ошибок её не отключили, чтобы библиотеки тоже проверялись и так далее.Если у тебя в этом месте проблемы, то и срастом такие же будут. Кто будет следить, что я не расставляю ансейфы для обхода борова? Кто будет следить, что я не подключаю левые либы? Итд итп. К слову даже в расте есть клиппи, а это отдельная тулза.
> В реальности же целый гугл не смог реализовать парсер json, и им пришлось брать его из растаБред.
> Кто будет следить, что я не расставляю ансейфы для обхода борова?Тут два варианта - у вас есть код-ревью или ты сам себе хозяин.
Если на код-ревью у тебя в растовском коде увидят сотни/тыщщи участков с ансейфом, к тебе возникнут вопросы. Почитают комментарии к этим участкам кода, присмотрятся, подумают, насколько это оправданно и заствят переписать. Повторится - скорее всего выкинут на улицу как диверсанта или неосилятора.
Ну а если ты сам себе начальник, то, получается, сам себе в штаны накладываешь и вообще не будет разговора об "кто следить будет" - сам себя обманываешь.
Ну так это работает и с C++. Есть кому следить за использованием анализатора кода - будет толк, нету - сам себе злобный буратино и никакой раст не спасет.
>> Кто будет следить, что я не расставляю ансейфы для обхода борова?
> Тут два варианта - у вас есть код-ревью или ты сам себе
> хозяин.Ну дык в проекте на с++ также.
> Если на код-ревью у тебя в растовском коде увидят сотни/тыщщи
> участков с ансейфом, к тебе возникнут вопросы. Почитают комментарии к этим
> участкам кода, присмотрятся, подумают, насколько это оправданно и заствят переписать.
> Повторится - скорее всего выкинут на улицу как диверсанта или неосилятора.Тоже самое для проекта на ___ (подставь что хочешь).
>Если у тебя в этом месте проблемы, то и срастом такие же будутПри чём тут раст? И да, в расте это делатся явно и проверяется примитвно, банальным grep. В плюсах вручную перелопачивать миллионы строк
>БредВашемнение реальность не изменит, а аргументов от вас нет
>>Если у тебя в этом месте проблемы, то и срастом такие же будут
> При чём тут раст? И да, в расте это делатся явно и
> проверяется примитвно, банальным grep. В плюсах вручную перелопачивать миллионы строкЗачем перелопачивать миллионы строк. Можно достаточно быстро увидеть как в проекте ведется работа с памятью, используются ли умные указатели, раи или они пишут как на си и жанглируют сырыми.
>>Бред
> Вашемнение реальность не изменит, а аргументов от вас нетЧел, ты видимо не переписывал большие проекты. Никто не будет переписывать на раст сложные подсистемы в хроме, а начнут с чего пропроще. Генерато qr кодов там или вот парсер json. Потому что повесточка такая от начальсва, а глупцам наружу скажут, что безопасно. Ну по CVE парсер json явно не на 1-ом месте.
>Можно достаточно быстро увидеть как в проекте ведется работа с памятью, используются ли умные указатели, раи или они пишут как на си и жанглируют сырымиИнтересно и как? Вот в расте - понятно, берём grep unsafe -rn и готово. В языках с GC скорее всего искать не нужно. Может быть ещё несколько ключей добавить. Что вместо unsafe подставлять в grep? Звёздочку - как мне отличить умножение от разыменновывания? Это уже не grep нужен, а какой-то специализированный инструмент. malloc искать? Но это не поможет, если кто то прошолся по коду, и заменил malloc на new, free на delete. Просмотреть пару файлов? А остальные как?
>Никто не будет переписывать на раст сложные подсистемы в хроме
>а глупцам наружу скажут, что безопасноДавайте посмотрим, что в новости:
>Отмечается, что переход на новый парсер может привести к прекращению разбора некоторого некорректно оформленного контента в формате JSON, но при этом он также решает проблемы при работе с некорректным JSON, который раньше вызывал аварийное завершение, а теперь приводит к возврату кода ошибки.То есть во-первых, старый парсер не следовал спецификации JSON, а во-вторых, вызывал аварийное завершение. Вы считаете нормальным, что парсинг такого простого формата выполняется так криво?
> То есть во-первых, старый парсер не следовал спецификации JSON, а во-вторых, вызывал аварийное завершение. Вы считаете нормальным, что парсинг такого простого формата выполняется так криво?Я просил в той новости привести пример такого некорректного джейсона, но никто не указал. Считаю ненормальным, что за столько лет существования хрома там был невалидный (по из словам парсер) и все им пользовались и не страдали. Это просто лапша на уши, наподобие причин плохой работы ютупа.
Я так и не понял почему надо создавать новый продукт, если можно подключить clang-tidy в CI/CD с проверкой на cppcoreguidelines-owning-memory (можно ещё кучу дополнительных проверок взять)? Суть такова: в CI/CD добавить этап, который будет блокировать PR изменений если они не прошли проверку линтера, зе энд.
> clang-tidyЭто отдельная тулза. Нужно в стандарте чтобы что-то было прямо в компиляторе.
Гуглу всякие "анализаторские" инструменты и фаззинг-тестирования не помогают в сишных/плюсовых проектах, всё равно ошибки просачиваются. Потому они и нахваливают раст и горлапанят о желании всю новую или ответственную нативную системщину в андроиде писать на расте.
Вот именно что нахваливают и горланят, но переходить не торопятся.
> о желании всю новую или ответственную нативную системщину в андроиде писать на растеНа фучсии они также делали, но с++ там тоже дофига был (задание подумать почему). И где теперь фучсия?
вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ? или вообще все без задней мысли как все работает ? капец просто, сколько это уже можно мусолить.
Опять про Настоящих Сишников™®© заливает.У Линуса спроси, он разъяснит как они там тридцать лет в ядре по этим граблям зодят и конца-края этому не видно.
Он наверное про RAII.
std::shared_ptr<Твой суперский тип>
и все, как только исчезнут владельцы ссылок на объект он освободится.
Прям капец трудно, дааа ? 1000 страниц прочитать надо, даааа ?Для клас-обертка вокруг ресурса с освобождением в деструкторе тоже пишется без каких-либо проблем...
раст делает это "по умолчанию"
с++ делает только то о чем его явно попросили.Затем статческий анализ не позволит васяну использовать чистые указатели и ресурсы без обертки с деструктором.
Все загоны растоманов от не знания базовых вещей, что етсь в с++ с 11 стандарта.
> std::shared_ptr<Твой суперский тип>и все, как только исчезнут владельцы ссылок на объект он освободится.
> Все загоны растоманов от не знания базовых вещей, что етсь в с++ с 11 стандарта.Лол. Если бы у тебя было знание базовых вещей C++, то был бы в курсе, что проблема владения не ограничивается возней с heap и RAII. Это проблема в дырявом фундаменте языка.
Как твой shared_ptr поможет в этом:
auto a = 0;
auto& b = std::max(a, 1);Вот у тебя b - висячая ссылка.
> с++ делает только то о чем его явно попросили.
C++ ничего не делает.
А ты делай так:auto a = std::make_shared<int>(0);
auto b = std::max(*a, 1);C++ ничего не делает за ленивых программистов.
>от не знания базовых вещейВот эта вот системная безграмотность очень красноречива.
> std::shared_ptr<Твой суперский тип>и все, как только исчезнут владельцы ссылок на объект он освободится.
Простейший двусвязный список и объект застрял навечно. А если это подкостылить слабыми ссылками, то уже можно получить висячий указатель
Если так старатся, то можно и ошибку памяти в Rust организовать https://github.com/Speykious/cve-rs
>Если так старатсяЧто значит стараться? Условный студент по вашему специально ошибки в курсовую вносит?
Значит что с правильным применением std::shared_ptr<> количество ошибок с памятью радикально уменьшается без всякого Раста.
Ну верит человек до сих пор в Деда мороза, - пускай и дальше верит!:)
>>> запросил памяти отработал, освободил. кто отменил культуру написания кода ? <<<Это хорошо звучит только в теории, на практике это не работает, - просто смиритесь с этим! Rust придумали не просто так!!!
Конечно не просто так, а из-за NIH.
При этом котроль выхода за границы массива, как бы, не помешает.
> вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ?Не понимаешь потому, что проблема владения не ограничивается возней с new/delete. В плюсах ты можешь в это вляпяться вообще без динамического выделения памяти.
Да, забей! Таким бесполезно что-то объяснять; cразу видно, что человек никогда не писал ничего серьёзного на С++, иначе он бы не писал глупости в стиле - да это же элементарно!ПС: Лично у меня бывали случаи когда приходилось писать код по 10, а то и по 12 часов в день. В таких случаях, лично я предпочту компилятор rustc, который скажет мне если я, скажем на 10 часу, когда я устал и моя концентрация упала, попытаюсь сделать какую-нибудь "элементарную" глупость, что я не прав, где именно, в чём не прав и самое главное как это исправить, вместо того, чтобы разбираться в "шаблонных портянках C++" из серии - упс извините, но "что-то" не так!
Только на раст для той же работы тебе понадобится 60 часов. Но да компилятор тебе точно скажет и много плохих слов про себя от него узнаешь.
> Только на раст для той же работы тебе понадобится 60 часов.Ты наверное написал тысячи строк на Расте, раз так уверенно утверждаешь.
Хотя, скорее всего, ты не написал ни одной.У гугла как-то получается, что раст-команды продуктивнее чем плюсовики.
Но туда конечно не васянов с улицы берут.> да компилятор тебе точно скажет и много плохих слов про себя от него узнаешь.
Компилятор не анон, он если ругается - то по делу.
"Сначала добейся", и сразу ссылка на авторитет. Просто ходячая демагогия.
>>> Только на раст для той же работы тебе понадобится 60 часов. <<<Разумеется в С++ есть херова туча библиотек почти на все случая жизни в отличии от Раста, - и именно поэтому вам кажется что писать код на плюсах быстрее, - и это нормально! Однако, если вы Раст не знаете, то вполне возможно вам и этого будет мало (и как это часто и бывает) вы вообще ничего не напишите!
но люди не поэтому пишут статьи "Почему я отказался от разработки игр на Rust"
Уважаемый анонимный иксперд, довожу до вашего сведения, что настолько большой разницы в скорости написания сферического кода в вакууме на Си, Си++, GoLang и Rust нет от слова совсем.
Хотя, в некоторых случаях, вам потребуется гораздо меньше времени для написания кода на Rust, но это касается тех случаев, когда что-то, реализованное в стандартной библиотеке Rust, отсутствует в стандартной библиотеке Си++ либо сделано там через жопу. Стандартная библиотека GoLang в этом отношении еще круче, особенно в плане обработки связанных с вебом вещей и генерации страниц по шаблонам.
Мы разумеется поверим на слово вам, анонимный иксперт с опеннета, а не опытным разработчикам на Rust, подробно описавшим в своих статьях причины дороговизны разработки на этом языке.
> ПС: Лично у меня бывали случаи когда приходилось писать код по 10, а то и по 12 часов в день. В таких случаях, лично я предпочту компилятор rustcА йа лучше меньше часов попрогаю :)
я даже не представляю, что можно прогать 12 часов, кек
"Hello, World!" на Rust? Borrow checker-с, знаете ли.
>вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ? или вообще все без задней мысли как все работает ?Вы не знаете про существование кучи? Где вы там память освобождать собрались?
> Вы не знаете про существование кучи?программист на "высокоуровневом безопасТном ЯП" - знать не должен!
>программист на "высокоуровневом безопасТном ЯП" - знать не должен!Зато плюсовики просто обязаны
Таким образом дальше может возникнуть подозрение, что кого-то после знакомства с OCaml посетила гениальная идея сделать члены class по умолчанию const и перенести часть работы сборщика мусора на этап трансляции. Но потом что-то пошло не так и автор Rust нарулил из проекта.
Видимо, подустал от пропитанного "любовью" сообщества.
У меня проблем с памятью в С++ вообще не было, хотя и смартпоинтерами практически не пользуюсь, и отслеживание владения объектами мне как-то не требуется - объекты просто не меняют владельца в течение всего времени жизни.
А вот чего не хватает, так это рефлексии и императивных синтаксических макросов.
>У меня проблем с памятью в С++ вообще не былоОткуда вы это знаете? Фазеры, например, находят неочевидные проблемы
Программа просто работает, например?
Неочевидные проблемы, которые как правило не имеют отношения к реальной работе приложения.
Это уже можно назвать Rust с классами?
Безопасная работа с памятью и 100% совместимость с существующей кодовой базой. И даже специалистов не нужно переучивать на новый язык. Что еще нужно для счастья.
> даже специалистов не нужно переучивать на новый языкАга, мечтай. У них в драфте есть пример:
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++-программисты творили под разлагающим влиянием Александреску, но примерно в ту сторону.
В общем, я желаю успехов данному начинанию, если получится, оно сделает раст ещё лучше.
Переучатся, куда денутся. Как будто это первое изменение стандарта, к которому нужно привыкнуть.Я тоже желаю успехов данному начинанию. Если получится, оно сделает Раст ненужным.
NVIDIA пишет драйвер на Rust, но тут многим виднее...
https://lists.freedesktop.org/archives/dri-devel/2024-March/...
точнее RedHat
> NVIDIA пишет драйвер на Rust, но тут многим виднее...И при чём здесь NVIDIA? https://www.opennet.me/60821-nova
Есть всего одна простая опция как радикально повысить безопасность C++ - отбросить поганое наследие Си:
- char* в коде? Ошибка, остановка компиляции.
- memcpy в коде? Ошибка, остановка компиляции.
- malloc/free в коде? Ошибка, остановка компиляции.
- сишное преобразование переменных? Ошибка, остановка компиляции.и.т.п.
Всё, безопасность вашего кода улучшена многократно.
Этого не хватит - останется как минимум ошибка на миллиард долларов - null.
Если запретить хранить "сырые" указатели, то нужно очччень постараться чтобы сломать себе ногу о nullptr. Так и на автомобиле можно в дерево въехать если очень захотеть.Вообще ошибки с nullptr - самые простые для отлова и исправления, всегда понято где навернулось и почему. В отличие от того же use-after-free, от которого у сишных программистов на лбу уже должна быть вмятина по форме ручки от грабель. Вот последнее реально на миллиард долларов.
>Вообще ошибки с nullptr - самые простые для отлова и исправления, всегда понято где навернулось и почему.Нет, же, нет. Даже мне, человеку не пишущему на c++ известно, что a[b] аналогично *(a+b). И если взять достаточно большой массив, то в итоге адресной арифметики хватит, чтобы указатель вышел за несколько первых зарезервированных страниц памяти и влез в чужую память. Насколько мне известно, это не единственный вариант
> что a[b] аналогично *(a+b)Есть такое, да. Только это не проблема null, а buffer overflow. Может придумают что с этим делать, как решили проблему use-after-free и владения памятью. Пока что есть range based for и всякие отладочные костыли.
В С++ есть некоторые средства, снижающие риск, хоть и не убирающие его полностью:
* std::vector и std::array вместо "сырых" массивов и их функция at()
* Итерация контейнеров без указателей и индексов через for (auto& obj: container), std::for_each()Но иногда надо и проверять индексы, да. Например, получил какие-то данные из сети и парсишь их. Но и в таких случаях, если ты контролируешь формат обмена - можно использовать форматы обмена, для которых есть готовые библиотечные парсеры. Например, JSON, CBOR, Protobuf.
>Но иногда надо и проверять индексы, да.Тогда чем это будет отличаться от условного Ocaml/Java, где границы точно так же проверяются? Смысл плюсов в скорости, а с такими ручными проверками они её потеряют. Тут уже ATS нужен или любой другой язык с зависимыми типами.
> Тогда чем это будет отличаться от условного Ocaml/Java, где границы точно так же проверяются?Сборка мусора? Джава машина? Функциональный или нет.
Отличий куча.> Смысл плюсов в скорости, а с такими ручными проверками они её потеряют.
Но смысла в типичный ошибках тоже мало.
Менять скорость на дыры в крптогрфической либе, может только очень пофигистичный человек.
Хочется спросить, а зачем тебе вообще эта либа?Тем более не все CVE это out-of-bounds.
Use-after-free и double-free тоже весьма распространены.Но кроме них, есть еще множество ошибок которые легко решаются более продвинутыми языками.
Например когда есть ENUM_1 и ENUM_2, естественно это инты, другое в дыряшке невозможно.
И сравнивает пограммист (самый лучший) две переменных разных енумом... и все отлично сравнивается.> Тут уже ATS нужен или любой другой язык с зависимыми типами.
Возможно это перебор.
Тут староверы не могут осилить логику заимствования, а ты предлагаешь им покрутить лямбда-куб и погрузиться в кортежи и монады))
> Смысл плюсов в скорости, а с такими ручными проверками они её потеряют.Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массива. Брат жив, рекомендую. Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороны. Предвижу ответ "Но я же потеряю одну секунду пока бегу за пивом!"
> Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массива. Брат жив, рекомендую.Думаю это редкость.
У вас это правило в проекте или ты сам так решил?
Если работаешь с коллегами, как они на это смотрят?> Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороны. Предвижу ответ "Но я же потеряю одну секунду пока бегу за пивом!"
Ты не поверишь сколько таких умственно отсталых погибают под колесами каждый год.
И главное когда его доктора собирают и спрашивают "О чем ты думал, дeбuл?" (c) то зачастую ответ "ну там автобус уже собирался уехать, я не хотел еще 10 минут стоять ждать"Так и в теме про уязвимость в очередной SSL начинается "проверки замедлят программу!"
>Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массиваИ что мешает это делать на языке где проверки делаются автоматически компилятором?
>Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороныЕсли нужна производительность, то нужны и зависимые типы. Если производительность не важна, то зачем тогда нужен c++?
Мыши, станьте ежиками ))
Кстати, походу Rust это только начало! На горизонте уже появляется "следующее поколение". Например, недавно наткнулся на вот такое:https://www.hylo-lang.org/
https://www.youtube.com/watch?v=5lecIqUhEl4
> Кстати, походу Rust это только начало! На горизонте уже появляется "следующее поколение".
> Например, недавно наткнулся на вот такое:
> https://www.hylo-lang.org/Конечно подражателей будет много.
Если уже плюсовики задумались что "заимствование это круто", то более гибкие языки тоже могут заимствовать идеи.У некоторых будут новыи идеи, которые возможно перекочуют в раст. А может нет.
Другие пока не приносят ничего супер ценного - как например зиг, который типа безопасный, но use-after-free позволяет.Будет ли hylo успешный? Может быть.
Но протолкнуться в ядро, в дрова или андроид будет очень сложно.
Так и Раст подражает другим языкам во многом. А тут буквально напрашивается следующий язык как он, только лучше, без его многочисленных недостатков. Тот же Zig это только первая ласточка и у него уже довольно большое коммьюнити, в основном бывших программистов на Расте.
На первый взгляд выглядит как наркомания. Объявлена непримиримая борьба не только с указателями, но и со ссылками. Вместо них предлагается писать какие-то subscripts, которые напоминают то ли питоновские генераторы, то ли плюсовые getter'ы на шаблонах. Дальше пошла квази-функциональщина, когда эти subscripts пихают в функции, и типа там должно что-то сгенерироваться без злых указателей, мягкое и плюшевое.На примитивных примерах то понятно, но не представляю как на этом писать что-то более сложное. Функциональщину вообще не перевариваю.
Язык с таким названием был бы настоящим подарком.
Да, но буковки "u" там все-таки не хватает
Раньше ради смеха си делали дифайнами внешне похожим на паскаль (фигурные скобочки бегин и энд заменяли) - ну хоть какая-то выдумка школьников. Сейчас просто взять Си и назвать его другим именем - норма. И обязательно рассуждения - как включить это в состав ядра. Отстаньте уже - займитесь делом.
> Сейчас просто взять Си и назвать его другим именем - норма.Это ти про сабж?
Ну я бы сказал что он на СИ не похож совершенно.> И обязательно рассуждения - как включить это в состав ядра. Отстаньте уже - займитесь делом.
А то что)? Будешь ныть?
Мы как раз делом занимаемся, стараемся сделать ядро хоть немного лучше. И разгрести ту кучу кода, которую диды навалили.
ИИ разгребет, чисто вручную это малореально.
Очень своевременная и важная инициатива, которая позволит повысить безопасность без переписывания кода существующих проектов. Только нужно еще добавить автотранслятор на новый стандарт.