Интесресное свойство BASH. Модель Rust + Bash.

Чем тебе some_string.parse::<i32>().unwrap(); не устроил?

Удалять гланды через жопу.

Найс траленк.

автогеном, к тому же )))

поддерживаю

Мне кажется, ответ в самом вопросе.

Rust в целом порадовал скоростью строгостью.

Но такого типа вещи оттолкнули: some_string.parse::().unwrap();

тебя в какую сторону подтолкнуть, к расту или от него?

string.parse::<i32>().unwrap()

Даже на сраном c++ это не так ублюдски выглядит :(

сказал А, говори и Б. как это вынгядит на с++ ?

std::stoi(some_string)

Ну тогда i32::from_str_radix

Ошибки будь любезен обрабатывать (или unwrap).

Для нормального разбора параметров можно взять clap или т.п.

Решил попытаться вникнуть в язык Rust

@

Не осилил вызов функции перевода строки в число

@

Смотрите у меня есть скрипт который при новых входных перекомпилирует всю программу. Просто и безопасно, а главное удобно!

Анон, срочно откликайся на все вакансии сеньера девелопера, ты сейчас на интеллектуальном пике. Лучше этого ты уже ничего не сделаешь

std::stoi, std::stol, std::stoll, std::stoul, std::stoull, std::strtol, std::strtoll, std::strtoul, std::strtoull

Отличается невообразимо. На целых 8 символов короче!

это еще чквачЁк эксепшены не обработал. наплевал на пользователя, так сказать.

Моя претензия состоит в том, что код нечитабельный: вместо того, чтобы ясно выражать изначальное намерение программиста (получить целое из строки), код представляет собой нагромождения из бойлерплейта и кракозябр.

+ Aswed

Тебе уже написали, уткнись: Интесресное свойство BASH. Модель Rust + Bash. (комментарий)

Спасибо. И воздержусь от осиляния Rust, хоть что-то есть в нём.

«Лучше этого ты уже ничего не сделаешь» Спс за совет. Не планирую

В итоге: для себя понял, что менять одно на другое смысла особенно нет. С на Rust. Т.е. для простой алгоритизации достаточно и С89 с стандартными библиотеками.

Держи нас в курсе.

Решил попытаться вникнуть в язык Rust.

Эка тебя вштырило. Многие с него уже слазят.

С 1 стороны, каждый раз вызывать compiler накладно. С другой стороны, при такой модели можно сделать ть в прекомпилированные файлы на каждый случай. А таких случаев с учётом скорости пользовательских машин, думаю, что не больше 15.

С учётом данной темы

Ну он же плюсовик. Зачем плюсовику обрабатывать экзепшены. У них на это есть сегфолты

std::{to,from}_chars – и никакого зоопарка.

Сегфолтов при эксепшне не бывает, не ври.

Кстати, а то, что паник в расте работает точно так же, как эксепшн, это чистая случайность, да?

Про сегфолты это был трололо. Но если серьезно, то не так же. Разница в том, что в расте у тебя в stderr вывалится стек вызовов как питоне каком-нибудь, что позволит тебе отдебажить проблему гораздо быстрее. Ну и еще в том, что в данном примере .unwrap() это явный вызов, что позволит еще на ревью кода увидеть, что такое нельзя пропускать.

От какие молодцы, возвращают Result, как в расте.

умнички!

Очень смешно :) Ради острот на форум и ходим.

Киллер-фича в простом и универсальном API, не зависящем от locale, а вовсе не в Result-подобном возвращаемом значении.

Разница в том, что в расте у тебя в stderr вывалится стек вызовов как питоне каком-нибудь, что позволит тебе отдебажить проблему гораздо быстрее.

У всех трех мажорных компиляторов поддерживается вываливание стек трейса.

Ну и еще в том, что в данном примере .unwrap() это явный вызов, что позволит еще на ревью кода увидеть, что такое нельзя пропускать.

Нет, потому что чужой код никто не ревьюит. Может быть, в крупных компаниях – но уж точно не в мелких программах на расте.

Да толку от этого «Result-подобного значения», если с ним ничего нельзя сделать, кроме как распаковать?

если в IDE печатать, то пофиг, автокомплит спасет

Но если серьезно, то не так же. Разница в том, что в расте у тебя в stderr вывалится стек вызовов как питоне каком-нибудь, что позволит тебе отдебажить проблему гораздо быстрее.

Основная разница состоит в том, что в rust (в отличие от c++ и питона) исключений нету, есть только unrecoverable panic.

Ну он же плюсовик. Зачем плюсовику обрабатывать экзепшены. У них на это есть сегфолты

Исключения предназначены для того, чтобы отделить код обработки исключительных ситуаций от кода реализующего основной сценарий работы. Нужно быть конченым дегенаратом, чтобы каждый вызов каждой функции оборачивать в отдельный try...catch, как вы с антошей тут хотите.

Были бы эксепшны по Саттеру – не нужен был бы закос под Result.

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

Мне кажется, ответ в самом вопросе.

И чем тебе нормальные способы не нравятся?

Вон vertexua предложил ещё один вариант. Тоже плох?

C++:

 entities.erase(std::remove_if(entities.begin(), entities.end(), [&entity](Entity other) {
        return entity == other;
    }), entities.end());

Swift/Kotlin всякие JS:

 entities.removeAll { $0 == entity }

Но такого типа вещи оттолкнули: some_string.parse::().unwrap();

Дело привычки, мне turbofish нравится, но можно и без него.

А вместо unwrap использовать ? или expect или ещё какой метод.

Можно и без turbofish, в чём проблема? От <> в глазах рябит? Ну так иди в лиспоподобные языки, там тебе будут одни ()

entities.erase(std::remove_if(entities.begin(), entities.end(), [&entity](Entity other) {
return entity == other;
}), entities.end());

Да, c++ ублюдский язык, в том числе потому, что описание логики на нём замусоривается бесполезным бойлерплейтом. Однако в rust по сравнению с c++ читабельность кода ещё снизили. Как заглянешь в него - блевать хочется.

Кстати, твой пример можно записать без лямбд, будет капельку лучше:

v.erase(std::remove(v.begin(), v.end(), entity), v.end());

в чём проблема

Проблема в том, что на нормальном языке это должно записываться вот так:

int(some_string)

ну раст мудрёный я на нем не так много писал, но именно по читабельности имхо лучше чем c++ получается, но во времена js/swift/котлин и это перебор.

хотя тут дело привычки, я как apple макака уже и objc без боли читаю.

И что же должно произойти, если some_string - не число, число не в десятичной системе, число, которое не влезет в переменную? Вот поэтому some_string.parse().unwrap(), а не int(some_string).

int(some_string)

И что же должно произойти, если some_string - не число

Поскольку int() не может выполнить ту задачу, которая на него возложена, то для него это - исключительная ситуация. На случай такой ситуации, где-то в сторонке от основного кода должен иметься обработчик исключительных ситуаций, которому и должно быть передано управление. Собственно, в c++/java/python этот подход широко практикуется.

Т.е. ты хочешь не обрабатывать на месте? Есть же some_string.parse()?.