он говорил, что твою тачку порутует любой кому не лень. запатчить это — минус 50% (т.е. сильно больше чем даёт smt). поэтому ну его нафиг.

Вот это - ты как посчитал?

я писал программы более миллиона строк?

в hello world можно всё и в main обработать.

я писал программы более миллиона строк?

Не знаю. Ты писал?

писал. поэтому и утверждаю.

Т.е. 3-10 уровней выше - это результат программы на миллион строк, которую ты написал (не буду спрашивать, сколько лет у тебя это заняло). Окей, обрабатывать ошибку нужно на 10 уровней выше. В чем проблема написать:

Resul<Something, Error> r = foo();
if (r.is_err())
  return r.unwrap_err();

Многословность как претензия не принимается: 1) в Си всё еще хуже, но никто не жалуется 2) макрос TRY пишется элементарно.

Как я мог пропустить эту нетленку. Во-первых в 90% случаев никакой Result не нужен, а в коде с качеством «руст» он не нужен в 99% случаев. Во-вторых, это как надо упороться, чтобы писать это:

fn write_info(info: &Info) -> io::Result<()> {
    // Early return on error
    let mut file = match File::create("my_best_friends.txt") {
           Err(e) => return Err(e),
           Ok(f) => f,
    };
    if let Err(e) = file.write_all(format!("name: {}\n", info.name).as_bytes()) {
        return Err(e)
    }
    if let Err(e) = file.write_all(format!("age: {}\n", info.age).as_bytes()) {
        return Err(e)
    }
    if let Err(e) = file.write_all(format!("rating: {}\n", info.rating).as_bytes()) {
        return Err(e)
    }
    Ok(())
}

Я лучше на пхп писать буду.

It's much nicer!

О да, у нас гениальное решение - очередной рандомный символ, только он ни от чего не спасает. Как я узнаю где и на чём у меня упало? Как я буду обрабатывать эти ошибки, если они разного типа? Опять тормозная дристня на vtable?

Очередной пример clang-way инноваций, когда придумывается кейс для демонстрации решения проблемы, которая является(по совместительству) единственным кейсом, в котором эта проблема решается.

Как я рад, что они «необучаемые» и в моём языке такого дерьма будет поменьше.

Я лучше на пхп писать буду.

Тебе лучше не писать вообще.

сколько лет у тебя это заняло

а если я писал не один? и до меня (тоже не один) писал это пару десятков лет? ты что, никогда windows, linux или oracle database своими глазами не видел?

В чем проблема написать

нет проблемы... до тех пор, пока ты не предоставишь код вызывающей функции.

сколько лет у тебя это заняло

а если я писал не один?

Значит, ты не имеешь права говорить «я писал программу на миллион строк».

до тех пор, пока ты не предоставишь код вызывающей функции.

?

ты не имеешь права говорить

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

до тех пор, пока ты не предоставишь код вызывающей функции.

?

ты показал как ты выбросишь ошибку. теперь покажи, как ты её обработаешь на первом уровне.

ты показал как ты выбросишь ошибку. теперь покажи, как ты её обработаешь на первом уровне.

Я не уверен, что правильно понимаю, что именно ты хочешь увидеть. Допустим, так:

if (r.is_err()) {
  // здесь обработка ошибки
}

Я не уверен, что правильно понимаю

может быть и так...

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

есть класс, который работает с файлами: открывает, закрывает, читает, пишет, перемещает указатель... ошибки шлёт через Result.

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

конструктор центрального класса программы хочет получить свой конфиг...

можешь такое набросать?

можешь такое набросать?

Нет. С одной стороны, мне лениво писать аж два класса (один из которых тупо дублирует FILE, а второй - просто функция). Но работа с функцией выглядит примерно так:

typedef SumType<IOError, ParseError> ConfigLoaderError;

Result<Config, ConfigLoaderError> load_config(const string&);

int main()
{
   int rc;
   string fname = "/etc/conf";
   Result<Config, ConfigLoaderError> r = load_config(fname);
   if (r.is_err()) 
      rc = workloop(r.unwrap());
   else {
      rc = 1;
      // если втупую
      cerr << r.unwrap_err() << endl;
      // если менее втупую  
      switch (tagof(r.unwrap_err())) {
         case IOError:
           // что-то делаем
           break;
         case ParseError: {
             ParseError& err = r.unwrap_err().as<ParseError>();
             cerr << "parse error: " << fname << ":" << err.line << ": " << err.msg << endl;
             break;
         }
      }
   }
   return rc;
}

int rc;

rc = workloop(r.unwrap());

это неинтересно :)

мы же большую программу пишем...

мы же большую программу пишем...

Я не пишу большую программу (в комментах на форуме, ага). Это был пример использования Result.

> Это был пример использования Result

в программе из двух функций? ну ок. записываю: раст годится для написания программ, состоящих из двух функций.

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

Это был пример использования Result

в программе из двух функций?

В примере из одной функции.

раст

Это Си++.

Лень цитировать каждое место.

Пройдёмся просто по тому, что сочится из коммента.

Все выкрики про то, что Clang (а иже с ним и libclang, и весь LLVM) говно я просто пропущу мимо ушей. Будем считать, что мир не использует всякие libclang для синтаксисов, построения статических анализаторов и так далее (только вот чего-то ту же подсветку синтаксиса все тянут из всяких clangd).

Про LLVM не умеет вообще ни в какие оптимизации, кроме базовых - в какие оптимизации LLVM не умеет по сравнению с GCC? Про пускать пыль повеселил - ну да, вот только из-за хайповости и непереносимости ГНУтости очень много людей используют Clang. И что-то вы не вспоминаете, каким монолитным куском говна является GCC.

Про проблему с оптимизациями аллокаций и возможные side effects - так стандарт разрешает на это забить (начиная с C++14, как я и отметил). И лично я не считаю данную проблему мелочной, особенно ввиду того, что много где можно просто повыкидывать std::vector заданного размера и заменить его на std::array (и это будет честной оптимизацией в рамках Стандарта).

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

Про смысловые оптимизации - да, это на данный момент решается только с помощью ручной разметки (отчасти можно решить контрактами)

Про то, что clang не выпилил динамическую аллокацию - ну так я говорил о том, что данная оптимизация не совершенна. GCC тут тоже говна сьел, и что?

Вроде никаких больше проблем не вижу, кроме как токсичной манеры речи. Ещё расскажете, где я ничего не понимаю?

Отвечу только на часть про оптимизации - ну так оптимизирующий компилятор на то и создан, чтобы из говна на входе делать как можно более оптимальную (по различным параметрам) исполняемую программу. Кто лучше справился с этой задачей, тот и больше молодец. Программист это человек, который умом не отличается => генерирует гуано вместо вменяемого кода => задача оптимизирующего компилятора это дело исправить. Понятное дело, что возможности не безграничны, но есть куда развиваться.

Ещё расскажете, где я ничего не понимаю?

Здесь он уже ничего не расскажет.

Да нормас. Если бы человек умел адекватно общаться, то с ним даже поговорить можно было бы.

Ну как, понравилось?

Да нормас.

Ясно.

Ох, совсем забыл сказать по поводу оптимизации new - ваш пример, где это ломается, не совсем верный, так как Стандартом оптимизация такого рода разрешена только для new expression, но никак не для operator new

И касательно ненужности C++ - ну вы поняли :) Приятных посиделок в Си мирке (или где там?).

Глупо отрицать, что человек явно в теме что-то да понимает. Но общаться нормально не умеет. Ну и со своими Си тараканами в голове. Что ж поделать.

Глупо отрицать, что человек явно в теме что-то да понимает.

После «да нормас» можно было ничего не добавлять.

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