LINUX.ORG.RU

о кондовых интерфейсах и быдлокоде

 , сложно


0

3

Основная «проблема» rust, по-моему, как раз в том, что этот ЯП был призван устранить - по принципу «за что боролись, на то и напоролись» -, и не позволяет писать говнокод легко и непринужденно.

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

На C можно представить такой код:

#include <stdio.h>

int main(int argc, char **argv)
{
    printf("%s\n", argv[1]); // здесь может быть какой-нибудь do_something(argv[1]), что именно не суть важно, но что-то определенно полезное
}

Тем временем, на расте придется писать вот так:

use std::env;

fn main() {
    let args: Vec<String> = env::args().collect(); // ???
    println!("{}", args[0]);
 }

Это очень слегка измененный пример из документации с rust-lang.org. Я даже не рассматриваю этот, на мой взгляд не к месту кулхацкерский, стиль экономии на переводах строки, а остановлюсь на «коллекционировании» аргументов коммандной строки.

Зачем мне создавать целый новый вектор? Только чтобы перейти от «сырого» массива строк к типо-безопасной структуре? Почему нельзя было предоставить какой-то упрощенный интерфейс, пусть даже если доступен только начальный итератор. Что-то типа такого:

use std::env;

fn main() {
    println!("{}", env::args() + 1); // если аргументов не передано, просто валимся с какой-нибудь паникой
 }
★★★★★

Я не знаю зачем ТЕБЕ создавать целый вектор, когда можно сделать так:

use std::env;

fn main() {
    if let Some(arg) = env::args().nth(0) {
        println!("First arg: {}", arg);
    }
}

Или, если плевать на ошибку, так:

use std::env;

fn main() {
    println!("First arg: {}", env::args().nth(0).unwrap());
}

Или если тебе нужны голые строки, просто использовать env::args_os в кодировке ОС, вместо UTF-8.

anonymous-angler ★☆
()

В чём проблема?

use std::env;

fn main() {
    for a in env::args() {
        println!("> {a}");
    }

    let x = env::args().nth(1).unwrap();
    println!("{x}");
}
AlexVR ★★★★★
()

Ничего не понял. Args это и так итератор. Ну напиши env::args().nth(1).

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

да, вот это похоже на то, что мне нужно

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

А, ну так ведь даже там написано:

The command line arguments can be accessed using std::env::args, which returns an iterator that yields a String for each argument

Сбор элементов в вектор - это просто для примера, что бы показать что это действительно итератор. На любом итераторе определена целая куча методов, collect - лишь один из множества

anonymous-angler ★☆
()

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

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

В Rust добавить structopt в зависимости и накидать структурку - дело нескольких минут.

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

Вы продолжаете мыслить в категориях С++

А причем тут плюсы? Человек написал код на Си, а вы вменяете ему «мышление в категориях С++».

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

Ты увидел, что если бы топикстартер заменил Си на С++, то ничего особо не изменилось. А я увидел, что у trex6 была оговорка «по-Фрейду». Мы разные вещи увидели. Я обратил внимание на нечто, что лежит в сфере психологии, а не в области технических вопросов.

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

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

Буквально замените sedом «С++» на «С» в комментарии и он останется корректным.

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

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

Буквально замените sedом «С++» на «С» в комментарии и он останется корректным.

Ну блин, я же сказал, что с этим никто не спорит. Зачем это говорить?

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

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

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

При этом было понятно, что как раз си конкуренции он не составит, где там раст под avr?

«Быть для avr» и «составить конкуренцию С» - это не одно и то же. Первое не является ни признаком, ни необходимым условием для второго, т.к. системы, которые строят на avr обычно слишком простые, чтобы актуальные проблемы С встали в полный рост на данной платформе. Разве что переполнение буфера, но поскольку системы относительно простые, даже это не является большой проблемой по сравнению с очень большими системами типа Линукс.

С другой стороны, если бы Раст потеснил С на x86, уже можно было бы сказать, что раст составил конкуренцию С.

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

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

Является необходимым условием, конечно же. Чтобы говорить о конкуренции, нужно покрывать тот же скоуп задач. И скоуп написания под embedded не покрывается текущим растом.

С другой стороны, если бы Раст потеснил С на x86, уже можно было бы сказать, что раст составил конкуренцию С.

Здесь используется непонятный термин «потеснил». Вы определите его одним образом, я — другим. Не может быть теснения без конкуренции.

loyd
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.