LINUX.ORG.RU

В C++ добавят Rust

 , , ,


2

3

Привет, ЛОР! Я тебе покушать принёс.

Опубликован черновик расширения Safe C++, представляющего собой надмножество языка с возможностью отключать в коде Undefined Behaviour и прочие небезопасные штуки. Safe C++ добавляет в язык также borrow checker, pattern matching и другие функции, знакомые и любимые программистами на Rust. unsafe блоки входят в комплект.

Пример кода:

#feature on safety
#include <std2.h>

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);
  }
}

Ошибка при сборке этого кода:

$ circle iterator.cxx -I ../libsafecxx/single-header/
safety: during safety checking of int main() safe
  borrow checking: iterator.cxx:10:11
        mut vec.push_back(x);
            ^
  mutable borrow of vec between its shared borrow and its use
  loan created at iterator.cxx:7:15
    for(int x : vec) {

Чтение за пределами обычных массивов также станет невозможным:

#feature on safety
#include <cstdint>

int main() safe {
  int array[4] { 1, 2, 3, 4 };
  size_t index = 10;

  // Panic on out-of-bounds array subscript.
  int x = array[index];
}

Результат:

$ circle subscript_array.cxx
$ ./subscript_array
subscript_array.cxx:9:17
int main() safe
subscript is out-of-range of type int[4]
Aborted (core dumped)

Таким образом, сишники и плюсисты наконец научатся писать нормальный код, который не падает с сегфолтами и не портит стэк. Так заживём!

Ссылка: https://safecpp.org/draft.html

★★★★★

Последнее исправление: hateyoufeel (всего исправлений: 2)

Ответ на: комментарий от anonymous

компилируй без эксепшенов и ртти, компилируй с -Os, не используй всяку масштабную муть из либы для простейших проектов. удали отладочную информацию. есть куча правильных советов как уменьшать экзешник с++.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от mittorn

Обычно есть выбор между безопасностью и эффективностью. Потому что 10% кода занимают 90% времени ЦП. А остальные 90% лучше написать безопасно, чем рисковать, что отрисовка эмодзи испортит данные в механизме управления буровой вышкой.

До Rust это делалось делением программы на две части: например, Tcl + C. Или C++ + Java.

Rust позволил использовать в обеих частях идентичный синтаксис и практически ликвидировать затраты на преобразование данных при вызове быстрого кода из безопасного.

Теперь safe C++ позволит то же самое, но при этом позволит в небезопасной части писать максимально быстрые программы (unsafe Rust слегка медленнее).

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от eao197

То, что нативное и на C или C++ (типа tar, 7z, konsole, kate, okular, vlc и даже Chrome) работает нормально и отзывчиво.

Чо-то я тебе не верю. Ну либо в твоём понимании, «нормально и отзывчиво» означает подождать запуск терминала 5 секунд.

Ну и выглядит написанное вами как откровенная херня.

Взаимно! Нет, серьёзно, гоняю кеды на ноуте из 2014 и всё достаточно не очень.

А если уж C++ взяли (предполагаем, что это был разумный выбор, а не «я больше ничего не знаю» или «а мне C++ просто нравится»),

Ты забыл «легаси» и «так сложилось». Это зачастую как раз основные причины.

навешивать на себя стоимость проверки при каждом обращении к массиву во время обработки больших объемов данных…

Кто тебе сказал что при каждом? Только при рандомных обращениях к элементам. Например, проход по массиву через цикл – если это не сраный for(auto i=0;i < array.size();i++){ ... array[i] ... }, за который в современном C++ надо по щщам бить – вообще никак не пострадает. Как и почти все прочие операции с массивами.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от alysnix

компилируй без эксепшенов и ртти

Это уже не C++, так как они входят в стандарт. Без исключений невозможно работать с основной частью стандартной библиотеки. И как работать с конструкторами классов без исключений? Без rtti тоже есть проблемы со стандартной библиотекой.

компилируй с -Os

Эта оптимизация практически ничем не отличается от -O2, кроме пары тройкой оптимизаций связанных с выравниванием и чем-то еще практически невлияющим на размер бинаря.

удали отладочную информацию

практически не влияет на использую память, пока не понадобится отладка.

есть куча правильных советов как уменьшать экзешник с++.

Размер бинаря - это не размер используемой памяти в рантайме.

anonymous
()
Ответ на: комментарий от hateyoufeel

Чо-то я тебе не верю.

Это сколько угодно. Равно как и я имею право не верить тому, что говорите вы.

Ну либо в твоём понимании, «нормально и отзывчиво» означает подождать запуск терминала 5 секунд.

Где-то секунды полторы после выбора из главного меню. Если консоль уже открыта и нужно сделать новую в отдельном окне через Ctrl+Shift+N, то вообще мгновенно.

Ты забыл «легаси» и «так сложилось».

Это отдельная история.

Это зачастую как раз основные причины.

Мне с 2020-го довелось поучаствовать в трех проектах на C++, которые стартовали с нуля и C++ там выбирался в качестве основного языка по совокупности причин (правда, в одном C++ использовался в качестве базы, а кастомизация уже делалась за счет интеграции в проект Python-а).

Кто тебе сказал что при каждом? Только при рандомных обращениях к элементам.

Потому что только в этом случае мы имеем принципиальный выбор между надежностью и скоростью. Это как раз вопрос, который я вам и задал, но на который вы не стали отвечать, а пустились в пространные рассуждения о криворукости C++ программистов.

eao197 ★★★★★
()
Ответ на: комментарий от Kolins

да успокойтесь уже, нужен, нужен; лор как-то всё забывает что кроме сейфити есть ещё алгебраические типы с матчингом, трейты, дженерики и продвинутая макросистема что будет сильно получше оопешной лапшички, полноценный мувинг опять же, а плюсовые аналоги всего этого вырвиглазны и завалены эзотерической информацией и прочими UB

zurg
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от eao197

Где-то секунды полторы после выбора из главного меню.

И это типа быстро? Полторы секунду чтобы консольку открыть? srsly?

Потому что только в этом случае мы имеем принципиальный выбор между надежностью и скоростью.

Нет, выбор куда интереснее.

Это как раз вопрос, который я вам и задал, но на который вы не стали отвечать

Сорян, тут тред интересный, я его пропустил.

ведь выбор же простой:

либо проверки на каждое обращение и тогда прощай производительность,

либо отсутствие проверок и тогда потенциальная запись за эту самую границу.

Но там, где производительность все еще имеет значение, то какой выход?

У тебя проблемы в рассуждениях, на которые я указал выше. В C++ лишь очень небольшая часть кода вызывает львиное количество ошибок при работе с памятью. При этом, утверждение, что, дескать, это всё сделано ради конской производительности, нужно ещё доказать, потому что зачастую производительностью там не пахнет.

Как я уже показал выше, при грамотной работе с массивами, о которых ты тут писал, лишних проверок практически не возникнет. Тем более, что перед глазами у нас есть пример Rust, на котором уже написано достаточно много кода, показывающего схожую с C++ производительность даже без использования unsafe{}.

Сколько у тебя горячих мест в среднем проекте, где прямо кровь из носа нужна скорость случайного доступа к массиву? Готов предположить, что это очень нечастая ситуация и такого кода не больше 2% от общего числа. А значит, можно ручками оптимизировать конкретно этот код, а в остальном включить автомагические проверки и перестать страдать уже.

В принципе, тут та же ситуация что и с UB: куча сишных шизофреников пишут, что мол UB нужно для таких-то там мегаоптимизаций, но пруфов что без UB оптимизации невозможны почему-то нету, а с выключением многих случаев UB через флаги компилятора и расширения почему-то ничего тормозить не начинает (больше обычного, я имею ввиду). Короче, типичная ситуация «диды страдали и нам завещали».

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от zurg

лор как-то всё забывает что кроме сейфити есть ещё алгебраические типы с матчингом

В SafeC++ по ссылке в ОП это есть.

трейты

Это есть в C++ уже полтора стандарта как. Называется концептами.

дженерики

Ну, темплейты же ну.

продвинутая макросистема

С этим тухло, но на дикой смеси cpp и темплейтов как-то плюсисты выруливают. Но соглашусь, нормальные макросы в C++ бы не помешали.

прочими UB

В этом, пожалуй, основная писечка этого Safe C++: он избавляется от UB по умолчанию.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

И это типа быстро?

Вы забыли про модель процессора. Он был тормозом еще в 2012-ом году. И свежие KDE еще большим тормозом его не сделали.

У тебя проблемы в рассуждениях, на которые я указал выше.

У меня нет рассуждений, я всего лишь хотел услышать ваш рецепт всеобщего щастя.

В C++ лишь очень небольшая часть кода вызывает львиное количество ошибок при работе с памятью.

Значит имеет смысл говорить только об этом.

При этом, утверждение, что, дескать, это всё сделано ради конской производительности, нужно ещё доказать, потому что зачастую производительностью там не пахнет.

«Зачастую не пахнет» – это пока что ваше оценочное и неподтвержденное суждение.

Как я уже показал выше, при грамотной работе с массивами, о которых ты тут писал, лишних проверок практически не возникнет.

Вы показали какой-то школьный пример, который не имеет никакого отношения к сколько-нибудь серьезной обработке данных.

Тривиальные случаи, когда нужно проитерироваться по массиву в C++ уже давно решаются посредством range for из C++11.

Готов предположить, что это очень нечастая ситуация и такого кода не больше 2% от общего числа. А значит, можно ручками оптимизировать конкретно этот код, а в остальном включить автомагические проверки и перестать страдать уже.

Даже если мы говорим о 2% от общего числа, то все равно остается вопрос о том, а как доверять результатам нашей ручной оптимизации?

Ну вот сейчас в C++ для векторов есть at и есть operator[]. Ничто не мешает использовать at в некритичных к скорости областях, а operator[] в критичных. Только вот чем определяется надежность кода, в котором operator[] задействовали?

Даже если по умолчанию в STL (и в других реализациях векторов, типа fbvector из Folly или small_vector из Boost.Container) включить проверки в operator[], то все равно людям придется дать аналог без проверок. Они начнут его использовать в 2% кода и… Опять же как этому доверять?

За счет тестов?

Ну так тесты можно применять и сейчас, без навешивания проверок в реализации operator[].

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Это уже не C++, так как они входят в стандарт. Без исключений невозможно работать с основной частью стандартной библиотеки. И как работать с конструкторами классов без исключений? Без rtti тоже есть проблемы со стандартной библиотекой.

гугл с++ стайл гайд рекомендует не использовать ни исключения, ни rtti. и нет у них проблем со стандартной библиотекой.

я вот тоже не встречал таких проблем, и неиспользую ни эксепшены ни ртти.

просто конструктор должен всегда выполнятся без эксепшенов.

alysnix ★★★
()
Ответ на: комментарий от alysnix

гугл с++ стайл гайд рекомендует не использовать ни исключения, ни rtti. и нет у них проблем со стандартной библиотекой.

«Рекомендации» не несут никакой ответсnвенности.

С -fno-exceptions вместо исключений abort, и ищи этот abort.

просто конструктор должен всегда выполнятся без эксепшенов.

Как из конструктора сообщить, что объект не создан и находится в неопределенном состоянии и использовать этот объект нельзя, в том числе нельзя дергать деструктор?

Только вот не надо мне говорить, что надо писать «правильные» классы с правильными конструкторами и методами инициалиации и тп. Скажи это сперва писателям стандартной библиотеки, только потом - пользователям этих стандартных библиотек и классов.

anonymous
()
Ответ на: комментарий от hateyoufeel

Ну пока что основная писечка Safe C++ в том что он ещё только будет, когда-то, а скорее всего нет, плюсовики в массе своей не воспримут, прям вот как ядерные сишники, а то что есть неоперабельно уродливо, рачт тоже не красавец, но в основном в эстетическом смысле, с семантической читаемостью сильно получше. Я ещё про растовую асинхронщину забыл, внезапно взлетевшую в ембедеде. И тут тоже можно сказать что в плюсах в последних стандартах есть co_чего-то там, но реально только пруф оф концепты, готового нет нихрена, а в рачте есть уже два фреймоворка и оба сходу завелись и поехали

zurg
()
Последнее исправление: zurg (всего исправлений: 3)
Ответ на: комментарий от monk

Время CPU всегда надо экономить. Устройство может питаться от батареи, а мир может страдать от глобального потепления. А попытки обеспечить «безопасность» нередко доводят до абсурда

mittorn ★★★★★
()
Ответ на: комментарий от anonymous

Основной источник расхода памяти - стандартная библиотека с iostream, string, container, которые дополнительно тянут exceptions, rtti и тп. А если еще с++20 с ranges подтянуть…

Что за пургу ты рассказываешь, собранный бинарь имеет SHR = 3.1 MB, RES = 3.2 MB. Итого он взял новой памяти у системы около 120 KB. Какой-то утрированный поклёп на спичках

kvpfs_2
()
Ответ на: комментарий от mittorn

Время CPU всегда надо экономить.

Даже в 70-е годы использовали shell и awk, а не всюду только Си и Фортран.

А уж нынче от того, что нагрузка ЦП будет не 2%, а 3% никто и не заметит.

monk ★★★★★
()
Ответ на: комментарий от kvpfs_2

Что за пургу ты рассказываешь

Что за штиль ты нашептываешь? С чем сравниваешь? Ни с чем?

Вот просто вывод «hello» c засыпанием на 10 сек, чтобы посмотреть «htop»

C++

#include <chrono>
#include <iostream>
#include <thread>

int main() {
  std::cout << "hello" << std::endl;
  std::this_thread::sleep_for(std::chrono::seconds(10));
}
& g++ -Os -g0 hello.cpp -o hello
res 3480
shr 3352

Lua

Хочу заметить, импортировал дополнительно сторонюю либу «luaposix»

local u = require 'posix.unistd'
print("hello")
u.sleep(10)
$ luajit hello.lua
res 2436
shr 2308
anonymous
()
Ответ на: комментарий от eao197

Вы показали какой-то школьный пример, который не имеет никакого отношения к сколько-нибудь серьезной обработке данных.

Покажи мне пример серьёзной обработки данных. Можно на примере опенсорцного софта на C++. Потому что тот код, с которым мне приходилось работать, часто представлял собой дикую лапшу на «Си с классами».

Тривиальные случаи, когда нужно проитерироваться по массиву в C++ уже давно решаются посредством range for из C++11.

Решаются кем? Кода, использующего for с счётчиком, всё ещё вагоны.

Даже если мы говорим о 2% от общего числа, то все равно остается вопрос о том, а как доверять результатам нашей ручной оптимизации?

Это другой вопрос, который решается другими средствами. Здесь штука в том, что мы можем сократить количество кода, в котором потенциально может быть ошибка, со 100% до 2%. То есть, в 50 раз. И мы сможем гарантировать, что в 98% кода этой ошибки не будет.

Ну так тесты можно применять и сейчас, без навешивания проверок в реализации operator[].

Чувак, средняя C++-обезьяна понятия не имеет про разницу между .at() и []. Я не шучу. Куча народа пишут код вообще не приходя в сознание. И ты прекрасно об этом знаешь.

Мы тут можем бесконечно обсасывать, что мол настоящие программисты на C++ таких ошибок не совершают, но статистика по CVE показывает совершенно другое.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от anonymous

LUA
RES SHR
2304 2304

C++
RES SHR
1792 1792

Даже тут С++ выигрывает, хотя это конечно бесполезный пример. Таблицы Lua намного более тяжелая чем простые структуры из Cpp.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от monk

А уж нынче от того, что нагрузка ЦП будет не 2%, а 3% никто и не заметит.

Кроме пользователей ноутбуков, у которых аккумулятор разрядится не за 10 часов, а за 3.

Тащемта, одна из основных проблем при настройке ляптопа под лялехом чтобы он работал долго – это выпилить всё тормозящее говно, просыпающееся не по делу. Недавно вот выяснилось, что Pipewire по чём зря камеру дёргает из-за бага. Починка этого привела к тому, что 2.5W потребления испарились. Причём на потреблении процессора этот баг вообще не сказывался.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

А тут лулз в том, что в нынешние времена процент от процессора не значит вообще нихрена. Пример: 100% загрузка проца бесконечным циклом и 100% загрузка проца каким-нибудь AVX-512 будет одинаково показываться с htop как 100%, но во втором случае проц будет жрать в 5 раз больше энергии.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Одна проверка индекса будет незаметна для современного ноутбука, это условие которое всегда переходит в одну ветку, и оперирует данными которые доступны по месту.

MOPKOBKA ★★★★
()
Ответ на: комментарий от hateyoufeel

Покажи мне пример серьёзной обработки данных.

Ну блин, мне больше делать нечего, ага. Из проектов для заказчиков таскать куски не могу, а искать чего-то похожего лень.

Могу из давно забытого студенческого: есть матрица исходных значений, нужно по ней пробежаться и пересчитать значения по каким-то формулам с задействованием соседних элементов. Т.е. для элемента [i, j] могут использоваться, например, [i-1, j], [i, j-1], [i, j+1], [i+1, j]. В зависимости от значений i и j у вас может не быть строк (i-1) или (i+1) или столбцов (j-1) или (j+1).

Таких штуковин в вычислительных задачах, насколько я помню, вагон и маленькая тележка.

Решаются кем?

Всеми, кто про это знает.

Здесь штука в том, что мы можем сократить количество кода, в котором потенциально может быть ошибка, со 100% до 2%. То есть, в 50 раз. И мы сможем гарантировать, что в 98% кода этой ошибки не будет.

Про гарантии ниже.

Чувак, средняя C++-обезьяна понятия не имеет про разницу между .at() и []. Я не шучу.

Тут вот какое дело. Я не против, чтобы в C++ в стандартных контейнерах добавили проверку в operator[]. Не знаю, правда, как быть с голыми указателями, работа с которыми все еще широко используется.

Но вот как события будут развиваться: народ быстро обнаружит, что operator[] дает оверхэд, а какой-нибудь новый unsafe_at – нет. И начнет фигачить повсюду unsafe_at вместо operator[].

И все гарантии пойдут по известному адресу.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от anonymous
$ ldd hello 
	linux-vdso.so.1 (0x00007ffe8332e000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f5c17845000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f5c176fd000)
	libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f5c176e2000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5c17503000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5c17a91000)

От запуска к запуску отличается, сейчас еще меньше RES 1692 SHR 1528

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от anonymous

Ты понимаешь что означают цифры, которые ты показываешь? shr - это память, которая разделяется между всеми процессами, общие либы; res - общая используемая память физическая. shr включена в res. Для нахождения памяти, которую взял конкретно данные процесс сверх разделяемой, надо вычесть shr из res

3480-3352=128
2436-2308=128

Всё, что ты можешь предъявить - плюсовые либы на 1 MB жирнее (крохи). Ну луа это и не плюсы, а лекговесный встраиваемый язычек.

Для контраста запусти какую-нибудь софтину на современном гуй тулките и прозрей - там речь идет о сотнях MB

Хочу заметить, импортировал дополнительно сторонюю либу «luaposix»

Ты не либу импортировал, а исходник с lua скриптухой, это совсем не одно и то же

kvpfs_2
()
Последнее исправление: kvpfs_2 (всего исправлений: 2)
Ответ на: комментарий от kvpfs_2

Согласен, скриптовый язык суммарно использует меньше памяти, даже используя сторонние библиотеки, и JIT компилируя в память.

Напомню, разговор начался с тезиса «С++ - для экономии памяти»

anonymous
()
Ответ на: комментарий от eao197

Могу из давно забытого студенческого: есть матрица исходных значений, нужно по ней пробежаться и пересчитать значения по каким-то формулам с задействованием соседних элементов. Т.е. для элемента [i, j] могут использоваться, например, [i-1, j], [i, j-1], [i, j+1], [i+1, j]. В зависимости от значений i и j у вас может не быть строк (i-1) или (i+1) или столбцов (j-1) или (j+1).

Ну, то есть, погоди. Для вот этой вот срани C++ вообще не нужен, это легко делается на каком-нибудь eDSL, который компилится напрямую в Си или даже в асм. Но даже в C++, такое проверить статически не то чтобы сложно. И такой код составляет даже не 2%, а 0.02% кода в системе. Соответственно, всё остальное можно без проблем завернуть в безопасное надмножество C++ без UB и с проверкой границ, и никто даже не заметит.

Хуже того, это в лёгкую делается на пердоне с numpy.

Но вот как события будут развиваться: народ быстро обнаружит, что operator[] дает оверхэд, а какой-нибудь новый unsafe_at – нет. И начнет фигачить повсюду unsafe_at вместо operator[].

Выходит, твой аргумент тут в том, что средний программист на C++ – тупой мудак и будет делать убогий говнокод, не потрудившись даже потрогать профайлер и посмотреть, действительно ли у него тормозит там где он думает (почти всегда тормозит где-то в другом месте). В принципе, так и есть, но забавно что пишешь об этом ты.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от anonymous

Напомню, разговор начался с тезиса «С++ - для экономии памяти»

Не только. Я вот вообще не воспринимаю софт, который на каком-нибудь питухоне, и это не субъективное, а опыт, значит обязательно будет тормозить и упадет где-нибудь в процессе.

А если конкретно про память - то плюсы весьма экономно её расходуют, даже со всей своей стд библиотекой, мы сейчас на это вместе посмотрели. Да, есть жирное дерьмо всякое, упомянутые современные попсовые гуй либы, например, но никто не заставляет, есть и fltk, например

kvpfs_2
()
Ответ на: комментарий от anonymous

Изучай «скриптуху»

ок, я просто через require скриптуху цеплял, я не луа эксперт 100го левела.

Вообще забавно, берется lua, которая встраивается в экосистему c/c++, экспортируется из нее апи и говорится: «смотрите, я вашему с++ рот шатал»

kvpfs_2
()
Ответ на: комментарий от hateyoufeel

Для вот этой вот срани C++ вообще не нужен

Вроде бы такие задачи успешно решают еще и на Фортране. Но пока еще и C++ активно используются.

делается на каком-нибудь eDSL, который компилится напрямую в Си или даже в асм

Кто-то, вероятно, так и делает.

Но даже в C++, такое проверить статически не то чтобы сложно.

Примеры такого можно увидеть?

Соответственно, всё остальное можно без проблем завернуть в безопасное надмножество C++ без UB и с проверкой границ, и никто даже не заметит.

Во влажных мечтах.

Выходит, твой аргумент тут в том, что средний программист на C++ – тупой мудак и будет делать убогий говнокод, не потрудившись даже потрогать профайлер и посмотреть, действительно ли у него тормозит там где он думает (почти всегда тормозит где-то в другом месте).

Нет, я такого не говорил.

но забавно что пишешь об этом ты.

Э… Тут не понял.

Я бы вообще хотел, чтобы C++ применялся реже, а писало бы на нем меньше народу.

eao197 ★★★★★
()
Ответ на: комментарий от alysnix

защищать от повреждения данных надо контрольной суммой, а не такими вот проверками, что мало что дают. данные могут быть повреждены, но тем не менее будут удовлетворять всяким простецким инвариантам, как с этим i_node.

Если ты не валидируешь входные данные (не важно откуда), то ты лох и к программированию тебя подпускать нельзя.

anonymous
()
Ответ на: комментарий от kvpfs_2

Потому что lua очень недооценненая «скриптуха» в нише для повседневных нужд (а не как встраиваемый язык).

Луа скрипт стартует 10-20 раз быстрее bash, 5-10 раз быстрее perl. Python вообще земляной червяк, улитка - ~200 раз медленнее. У lua нормальный синтаксис по сравнению с ними, через год вполне можно разобраться с тем, что было написано раньше.

И вот эта «скриптуха» сравнивается по потребляемым ресурсам в рантайме с с++ для повседневных задач.

А с++ явно надо думать над оверхедом стандартной библиотеки, что для вывода одной строки приходтся подключать весь комбайн стандартной библиотеки.

anonymous
()

Таким образом, сишники и плюсисты наконец научатся писать нормальный код, который не падает с сегфолтами и не портит стэк. Так заживём!

Нет, они либо свалят на раст либо научатся писать unsafe{} везде.

черновик расширения

Зная как работает комитет, ждём его в стандарте самое ранее в C++32. Потому ещё 10 лет ждём пока его заиспользует значимая часть используемых библиотек. При этом на нативный Rust переписывают с такой скоростью что эти библиотеки уже никому не нужны будут, как и плюсы, который даже с безопасностью останутся плюсами.

anonymous
()