С нормальной квалификацией у тебя все будет надежно и в C++ в современном его состоянии, с ситуацией в отрасли и пр. А если у тебя с квалификацией проблемы, то никакой Rust не спасёт.
Меньше выделений памяти => меньше фрагментация кучи со временем. + для сишечки это еще и меньше free => меньше мест, где можно налепить утечек памяти.
Еще мог бы наплести про локальность данных, но это не сильно решает в данном случае.
А со стоимостью выделения/высвобождения памяти что?
А со стоимостью strlen/memcpy что? Почему длина строки не таскается вместе со строкой, а каждый раз вычисляется заново? Почему строки не copy-on-write с подсчетом ссылок (что позволило бы избежать преждевременного выделения памяти и копирования)? Если мы считаем каждое выделение, то почему в коде не рассмотрен отдельно случай, когда выделять ничего не надо, а можно просто скопировать указатели из аргументов функции в тело структуры (передать владение)?
Вывод: обсуждаемый кусок кода — это перемалывание байтов ради перемалывания байтов, бессмысленное и беспощадное.
Эта проблема уже 100500 лет назад решена различными тулзами. А вообще нормальная квалификация приведёт к тому, что такие баги будут случаться раз в год, когда ты с похмелья что-нибудь закодишь. А это жалкие доли процента от общего числа багов. Так что даст нам раст?
Эта проблема уже 100500 лет назад решена различными тулзами.
Ссылку на гугл я тебе уже дал. Твои теории о том, что проблема решена, не состоятельны.
И да, ололо, тулзы для си/с++! Это ты про уродцев на костылях, вроде cppcheck и valgrind? Они иногда кое-что находят, но ни одна из не может дать гарантий, что твоя программа однажды не скопытится с сегфолтом. Зачем они, такие убогие, теперь нужны?
А вообще нормальная квалификация
Да-да, писать код без ошибок — неужели это может быть сложно? :D
Ты читать умеешь? У меня нет ни слова про отсутствие ошибок. Лучше ответь на вопросы о количестве описанных тобой ошибок и их соотношении с общим числом ошибок. Вспомни свои проекты, посмотри на чужие. А по поводу инструментов не баттхерть, она пользы пока людям принесли больше, чем раст =)
Я просто не вижу смысла переходить на новый язык ради исправления меньше 1% ошибок. При том, что производительность пока не навысоте, синтаксис сомнителен, рантаймные средства фиксированы(придется, скорее всего, что-нибудь своё unsafe'ое пилить в реальной жизни). Да и вообще язык не зарелизен ещё...
Пройдись глазам по списку, и увидишь, что львиная доля проблем состоит из: * проблемы с memory safety (всевозможные buffer overflow, use after free, invalid array index, out of bounds, и так далее, и тому подобное) * проблемы с race conditions * проблемы с неспособностью отследить время жизни (double free, use of expired file descr, return of stack variable address, и тому подобное) * проблемы с ненужной мутабельностью (Assigning instead of Comparing) * проблемы с нарушением типизации
Всё, что я перечислил, в Rust невозможно.
Давай, честно открой ссылки и честно подсчитай. Это действительно впечатляет.
Был в восторге от юлечки, пока не попробовал на ней писать программы. Тут и вылезает неадекватность авторов и отсутвие у них опыта. Индексация массивов от единицы? Нуууу, оооокей. Но когда слайсы включают верхнюю границу - это уже явный признак школоты, не читавшей Дейкстру. Потому что в юлии длина l[start:end] не равна разнице между end и start, как во взрослых языках. А равна end - start - 1. Это сраная +/-1 в юлечкиных программах вылазит повсюду. Как и в матлабовских, например. Но зачем мне второй сраный матлаб? Такого говна достаточно одного на весь мир, чтобы он содрогнулся. Но юлечкины родители решили выйти на новый уровень. Все приличные языки приучают писать лаконичный, идиоматический код, и он в них работает. Только не в юлии. Сами авторы на голубом глазу пишут: не надо складывать матрицы так: X = A + B. Надо так: for col=1:n, row=1:n X[row, col] = A[row, col] + B[row, col]. Вдобавок надо помнить, что у юлечке уёбищный порядок индексов, как в фортране (и в матлабе). Такое впечатление, что авторы ходили по помойкам истории и собирали все неудачные решения, от которых в цивилизованном мире давно отказались. Почему в XXI веке компилятор не может оптимизировать векторизованный код? Самое весёлое, что есть костылик Devectorize.jl, который разворачивает векторизованные операции до тупых фортран-стайл вложенных циклов - и они работают быстрее! Почему нельзя встроить это во встроенный оптимизатор? Потому что СРАНЫЕ КРЕТИНЫ. Потому что они всерьёз не понимают, чем плох низкоуровневый код и операции с индексами, чем плоха индексация массивов от 1 и закрытые интервалы. Просто элементарных вещей не осознают, что в тарболе julia-x.x.x.tar.gz дожет быть каталог julia-x.x.x, а не просто julia, что не надо в тарбол julia-x.x.x.tar.gz класть llvm-x.x.x.src.tar.gz, gmp-x.x.x.tar.gz, fftw-x.x.x.tar.gz и ещё килотонну зависимостей. Из какого заповедника они к нам выползли? Строгая типизация - че? join([«a», «b»], None) спокойно нам выдаст «aNoneb» - это что за ПХП вообще? Понятные сообщения об ошибках, удобный бэктрейс? У нас его есть:
ERROR: c not defined
in include at /usr/bin/../lib/julia/sys.so
in process_options at /usr/bin/../lib/julia/sys.so
in _start at /usr/bin/../lib/julia/sys.so (repeats 2 times)
while loading /tmp/generate_latex_symbols_table.jl, in expression starting on line 23
Штоэтааа? Они про бэктрейс только в книжках читали? Пускай попросят маму сегодня перед сном им питон показать - вдруг им что-то умное приснится. А лучше пускай заползут под кровать и поплачут за плинтусом, потому что быть таким безудержным мудаком - СТЫДНО. Вывод редакции - julia не предназдачена для написания программ. Это вообще не язык программирования, а интерактивный калькулятор с расширенными возможностями скриптования. Убедительная просьба в тредах о языках программирования эту поделку не поминать.
Если тебе похрен на производительность, безусловно нерелевантно.
Кстати, а как вообще управлять памятью без адресной арифметики? Например, slab'ы нарезать? Или «кастомные аллокаторы не нужны»?
Я уже понял, что в стране единорогов эльфы 80-го уровня привыкли к тому, что весь критически важный софт состоит из безукоризненного кода, написанного высококвалифицированными профессионалами как ты сам. Однако, в мире реальном OpenSSL, каким бы говном по твоему мнению он ни был, является самой распространённой библиотекой шифрования, в котором такая «1% случаев» ошибка была допущена. Последствия этой маленькой неприятности, надеюсь, знаешь.