LINUX.ORG.RU

Изучая Rust...

 , ,


1

4

Здравствуйте. Пытаюсь реализовать список на Rust. Вот что у меня получилось:

use std::fmt;

struct Node {
    value: i32,
    link: Option<Box<Node>>,
}

impl Node {
    fn new(value: i32) -> Node {
        Node { value: value, link: None, }
    }

    fn append(&mut self, value: i32) {
        match self.link {
            Some(ref mut node) => node.append(value),
            None => self.link = Some(Box::new(Node::new(value))),
        }
    }

    fn length(&self) -> i32 {
        match self.link {
            Some(ref node) => node.length() + 1,
            None => 1,
        }
    }

    fn insert_after(&mut self, value: i32, after: i32) -> bool {
        if self.value == after {
            self.link = Some(Box::new(Node { value: value, link: self.link.take() }));
            true
        }
        else {
            match self.link {
                Some(ref mut node) => node.insert_after(value, after),
                None => false,
            }
        }
    }
}

impl fmt::Display for Node {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "{}", self.value)
        while
    }
}

fn main() {
    let mut stack = Node::new(1024);

     stack.append(67);

     println!("{}", stack);
}

Подскажите, как можно напечатать все элементы списка? В текущей реализации выводится только первый элемент.


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

Зачем этот ужас? На расте можно писать так:

Ну тут тебе повезло, что я написал None :) А вот так как записать:

print( c.id ?? "-" )

Где c.id - число?

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

Ну, например, было:

В расте нельзя записывать без скобок, то есть будет:

if(something) {
  //then_action();
} else {
  else_action();
}
Что, кстати, избавляет от ещё одной популярной ошибки, которую, разумеется, «профессионалы не делают». И в таком варианте записи закомментированный код никуда со своего места не денется, исказить смысл будет сложно.

И если тело while можно представлять в виде одной точки с запятой

В расте нельзя и я не вижу никаких проблем в этом.

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

Что-то в этом роде http://is.gd/JkHjx8
Mutex

Не интересно. Вот у меня есть lock-free реализация на С++, может я ее даже покажу, если будет вариант на Rust.

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

И если тело while можно представлять в виде одной точки с запятой, то почему нельзя того же делать с if-ом?

Тук-тук, есть кто дома? Потому что способствует появлению легконабираемых и труднозамечаемых багов.

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

Не интересно

Тебе лично - может и нет, а так еще как интересно.

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

Тук-тук, есть кто дома? Потому что способствует появлению легконабираемых и труднозамечаемых багов.

Кто бы говорил. Rust это ли не тот язык, где легко можно объявить переменную заново:

    // ....
    let x = 1;
    
    // ....
    let x = 123;
    ....
    
    // ....
    println!( "{}", x );

И не получить даже предупреждение.

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

Не согласен - приводи примеры того, чем он отличается.

static_cast не может константность убирать, например. Ну и int* в double* им кастовать нельзя.

Да и что конкретно не соответствует действительности?

То что асм не используется в расте: https://github.com/redox-os/redox/search?utf8=✓&q=asm

Про либц позже.

Зачем мне писать 10строк там, где я могу написать одну?

Для читаемости. Хотя если ты всегда пишешь f1(), f2(), f2(), ... f100() в одну строчку, то вопросов нет.

//ставь нормальный скобки.

Это зависит от принятых соглашений в проекте. Нормальны оба варианта.

Это типа затралил?

Нет, потому что в расте так тоже нельзя.

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

Про лайфтаймы меня поймать не получится, не фортануло.

И что это доказывает?

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

Скажем, статические анализаторы и валгринд тебе не нужны

Да, ибо для того(ничего), что я пишу - они бесполезны.

а в моей практике они отлично работают и помогают

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

Аналогично с ревью - глаз замыливается, можно что-то и пропустить.

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

Более того - если человек ещё не вник в проект или даже банально «слабый программист», то глубоко в код он не вникнет. А такие явные вещи как unsafe бросаются в глаза.

Не вник - это проблема «слабый». Уже сотни лет есть идешки и никаких проблем с вхождением нет. Ну вот ты назвал истинную причину - почему везде лапша, базар и почему никто не может в язык. Разнородность с перевесом в лс и тонны легаси дерьма.

Можно это попробовать обсудить, но если ты скажешь, что безопасности нет из-за наличия unsafe, то я опять же, не понимаю о чём тут говорить.

Ещё раз. Раст пиарится как БЫСТРЫЙ SAFE, а кресты как БЫСТРЫЙ UNSAFE, а в конечном итоге выходит так, что «быстрый» раст - это unsafe, который рядом не валялся с возможностями си - нахрен мне такой unsafe?.

В этом и проблема. Не существует быстрого safe в расте, а существует нечитаемая лапша. А само safe ничем не safe и не быстрее любого другого safe.

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

Достаточно вернуться в начало ветки, где ты выдавал поднутую форфан треадsafe за фичу, а не ограничение.

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

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

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

Кто запишет коротко (в частности печать) это на Rust?

struct Customer {
    tel: Option<i32>,
}

fn main() {
    let c = Customer{ tel: Some(12345678) };
    println!("{:?}", c.tel);
}
DarkEld3r ★★★★★ ()
Ответ на: комментарий от eao197

И если тело while можно представлять в виде одной точки с запятой, то почему нельзя того же делать с if-ом?

Кстати как минимум clang по дефолту достаточно адекватно предупреждает о таком коде:

~$ cat ./test.cpp
int main() {
    if( 1 );
}
~$ clang++ ./test.cpp
./test.cpp:2:12: warning: if statement has empty body [-Wempty-body]
    if( 1 );
           ^
./test.cpp:2:12: note: put the semicolon on a separate line to silence this
      warning
1 warning generated.
~$ cat ./test.cpp
int main() {
    if( 1 );
    else {}
}
~$ clang++ ./test.cpp
~$
anonymous ()
Ответ на: комментарий от registrant27492

а, это такая мощная система лайфтайма, полностью статическая конпелятором выводимая - посмеялся.

Ну хватит ерунду нести-то. Это к лайфтаймам вообще отношения не имеет. Если угодно, это «приведение типов».

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

Если осилишь послушать и выкатить примеры - я тебе даже объясню.

Я действительно хочу «осилить», хотя и уверен, что мы говорим просто о разных вещах. Давай ты более прямо скажешь каких примеров ожидаешь.

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

Маладетс, еще раз использовал вариант с None. Ну повезло с очень частным примером, что у меня в голову сходу растовский None пришел. Но пример то совсем о другом.

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

В расте нельзя записывать без скобок

Какой-то странный разговор получается. Мой поинт был в том, что к C++ выдвинули очень странный список претензий. Докопались до точки с запятой в if-е — это сильно, да. У языка полным-полно актуальных проблем, но докапываться будем до точки с запятой в if-е.

В расте нельзя и я не вижу никаких проблем в этом.

Имхо, дело вообще не в том, что в Rust-е можно, а что нельзя. Дело в другом: есть старый язык со своим наследием. В этом наследии много и плохого, и хорошего. Тут появляется Rust со своими фишками и плюшками, но без всякого наследия вообще.

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

С другой стороны, если в языке есть реально полезные фичи, то вопрос в том, насколько Rust применим в реальной разработке. Или в том, в каких именно условиях он применим. Скажем, если для C++ есть готовые библиотеки, то чем их заменять в Rust-е? И если для Rust-а готовых библиотек нет, то как быть в этом случае?

Вот по таким вещам интересно сравнивать применимость Rust-а вместо C или C++. А не по претензиям к operator,().

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

g++ 5.3.0 с флагом -Wextra так же предупреждает.

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

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

Иксперд в треде, блин.

Скажем, неинициализируемые по-умолчанию переменные к подобным последствиям приводят гораздо чаще. А если взять тему, скажем, exception safety или какой-нибудь rule-of-five, то там вообще целые рассадники... Но докапываться нужно именно к точке с запятой после if-а. Как будто такие ошибки часто встречаются в дикой природе.

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

static_cast не может константность убирать, например. Ну и int* в double* им кастовать нельзя.

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

То что асм не используется в расте: https://github.com/redox-os/redox/search?utf8=✓&q=asm

pub unsafe fn fast_copy(mut dst: *mut u32, mut src: *const u32, mut len: usize) {
    asm!("cld
        rep movsb"

Смешно. Ну паста с гиса. Слишком убого. Уровень детсада.

А эти «{rcx}» - скобочки это пунктик такой? Нахрен они везде их суют?

Для читаемости. Хотя если ты всегда пишешь f1(), f2(), f2(), ... f100() в одну строчку, то вопросов нет.

Ещё раз - это не читаетмость, а балабольство. Никаких агрументов не последовало. Хотя выше даже с «читаем» стилем скобок ты немного сел в лужу - бывает, когда веришь.

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

Это зависит от принятых соглашений в проекте. Нормальны оба варианта.

Нет, нормальный только один вариант и это скобки на той строке, где if(). Это а) короче, б) ты только что сам доказал, что они безопасней.

Нет, потому что в расте так тоже нельзя.

А, т.е. while((*out++ = *in++)); - уже не прокатит?

Наверное так лучше.

while(*out = *in)
{
++out;
++in;
}

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

Ну хватит ерунду нести-то. Это к лайфтаймам вообще отношения не имеет. Если угодно, это «приведение типов».

А, т.е. оно само не может кастануть? Ещё хуже.

Насколько я понимаю все нелюбят автокасты из-за их не SAFE, но ведь у руста самый лучший конпелятор - почему нельзя отследить константу и передать её нормально, а не по-идиотски?

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

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

Пока цари сишки и свифта пытаются доказать ненужность Rust и просто тупят

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

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

Я действительно хочу «осилить», хотя и уверен, что мы говорим просто о разных вещах.

Хорошо. У тебя там есть «шаренье ссылок», владение, аллокации и прочие куллстори.

Зачем нужно шаренье ссылок? Зачем нужны ссылки? Зачем нужно владение? Зачем нужны аллокации?

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

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

Давай ты более прямо скажешь каких примеров ожидаешь.

Сказал.

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

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

Вот тебе та же задача - print( c.id ?? "-" ) на Rust. Хочешь, чтоб я перестал тупить, напиши свой вариант. Это будет короткий ответ, полезный, и прекратит мой тупняк. Не можешь - продолжай занудствовать.

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

Не создаешь флейм и не можешь ничего сказать, кроме занудства от старпера

Царь свифта негодует. Я по крайней мере говорю на тему топика, советую и тебе придерживаться ее.

Вот тебе та же задача - print( c.id ?? "-" ) на Rust. Хочешь, чтоб я перестал тупить

Пока ты тупишь хотя бы отдаленно по теме топика - не вопрос, тупи.

напиши свой вариант.

А для начала мне сходить выучить свифт? Не, спасибо.

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

Я по крайней мере говорю на тему топика, советую и тебе придерживаться ее.

Чушь. Ты всегда старательно обходишь любой код, чтоб случайно не облажаться. Потому и рассуждаешь на отвлеченные темы. А данный топик - про код.

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

А для начала мне сходить выучить свифт? Не, спасибо.

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

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

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

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

ААА ТЫ ЗНАЛ!!!11

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

ААА ТЫ ЗНАЛ!!!11

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

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

+785 −369

Сильно. Что сказать-то хотел? Осилилась замена убогой обёрточки? Ну сильно, а дальше? Во понял бы я, если бы в русте не нужна была обёртка и всё было бы safe и fast, ан нет.

народ требует начала банкета

Приходи когда кор перепишут.

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

народ требует начала банкета

Приходи когда кор перепишут.

По ссылке вообще нечего обсуждать, там протухшее и отклоненное предложение, пусть и вежливо отклоненное. При том что libgit != git.

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

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

Ну пацан сказал, что нам народ желает, а подлые буржуи-консерваторы сишные лс"ы - недают им свободы.

При том что libgit != git.

Ну это понятно, что это не кор, а обёртка по первому же взгляду. Но вроде как хорошая обёртка это то, что не умеет сишка и должен 100% уметь куллязык, но что-то не смоглось. -300 +700.

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

По ссылке вообще нечего обсуждать

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

там протухшее и отклоненное предложение

Там proof-of-concept. Судя по реакции - удачный.

При том что libgit != git.

Вообще пофиг.

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

А вот так как записать:

Ну так кратко не получится, да.

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

И не получить даже предупреждение.

Ты же не получаешь предупреждения в таких случаях:

int i;
{
    int i;
}
Кстати, когда впервые эту фичу увидел, то мне начали доказывать, что мол оно очень удобно и есть в куче языков и я просто не привык. На тот момент, переубедить меня не удалось, потом поменял точку зрения. Периодически приходится что-то типа такого писать (очень условно):
void f(const T& value) {
    const auto& convertedValue = convertValue(value);
    const auto& updatedValue = updateValue(value);
}
Типы разные, так что выстрелить себе в ногу затруднительно. А вот новые имена, на ровном месте, придумывать приходится. Хотя, конечно, можно возразить, что они улучшат читабельность.

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

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

Ага, вот только есть ещё одна проблема: всё вокруг - «дерьмо». И или мы будем «держать его на плаву» или останемся ни с чем. Ты ведь не рвёшься переписать всё «по уму».

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

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

Не вник - это проблема «слабый». Уже сотни лет есть идешки и никаких проблем с вхождением нет.

Всё-таки не соглашусь. Проекты - они разные по объёму и сложности бывают. Всё-всё в одну голову не (всегда) реально поместить.

а кресты как БЫСТРЫЙ UNSAFE

Тут тоже можно поспорить. Многое в последних стандартах (и вполне успешно) делается как раз для упрощения «без потери скорости». Да и когда речь о «безопасности» заходит, то тут же начинаются разговоры - мол никаких проблем давно нет, «если нормально писать». А на самом деле, есть. Другой вопрос насколько тут «чудо-инструменты» помогут.

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

И ты всё-таки не прав относительно «зерокост» в расте. Много вещи действительно статически гарантируются. Естественно, ценой (местами «довольно жёстких») ограничений.

Приведи мне пример использования того, что ты считаешь относящимся к языку.

Ну паттерн матчинг с местными enum, опять же? У нас в проекте активно используется boost::variant с самописным «подобием» матча - получается менее красиво/удобно. Или то, что указатель/optional нельзя разыменовать без проверки. Да, это решается «всего-лишь внимательностью», но я предпочту чтобы компилятор тут подстраховывал.

А ещё лучше - макросы.

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

Но пример то совсем о другом.

Это было не очевидно, ну да ладно. Давай с другой стороны зайдём - часто такое нужно? Мне как-то чаще пригождается get_value_or из того же плюсового optional, которое работает так же как растовое unwrap_or.

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

Мой поинт был в том, что к C++ выдвинули очень странный список претензий.

Список не мой, если что. Хотя тоже считаю, что пользы от точки с запятой после if. Да, компиляторы (уже) предупреждают и проблем, в общем-то, тоже нет. Но тащить такую «возможность» в новые языки нет смысла, как и жалеть об их утере.

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

Если что, я пишу на работе именно на С++ и, в отличии от некоторых хейтеров, совсем не страдаю при этом. (:

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

И если для Rust-а готовых библиотек нет, то как быть в этом случае?

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

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

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

Справедливости ради, раст и этиму препятствует. Обращение к переменной без инициализации - ошибка компиляции.

Как будто такие ошибки часто встречаются в дикой природе.

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

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

Смешно. Ну паста с гиса. Слишком убого. Уровень детсада.

Все применения просмотрел? (Мне лень, честно.)

А эти «{rcx}» - скобочки это пунктик такой?

Синтаксис макроса такой.

Ещё раз - это не читаетмость, а балабольство. Никаких агрументов не последовало.

Ну а как можно спорить с return f(a), f(b), f(c);? Вот серьёзно - если тут не запятую, а точку с запятой применить, то что изменится?

Хотя выше даже с «читаем» стилем скобок ты немного сел в лужу - бывает, когда веришь.

Давай без этого с лужами, ок?

Нет, нормальный только один вариант и это скобки на той строке, где if(). Это а) короче

Короче - не всегда лучше. Ну и дофига проектов используют вариант с скобкой на отдельной строке. Не вижу в этом ничего плохого. И сторонники такого подхода тоже приведут «аргументы» - мол так визуально лучше видно и т.д. Вес аргументов примерно одинаковый.

Наверное так лучше.

Это сарказм или как? Ну и у цикла вполне может быть пустое тело, если так уж хочется. Хотя while((*out++ = *in++)) действительно не прокатит.

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

Если что, я пишу на работе именно на С++ и, в отличии от некоторых хейтеров, совсем не страдаю при этом. (:

Самое лучшее в более-менее современном Си++ - то, что из него можно сделать эрзац-Rust :)

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

А, т.е. оно само не может кастануть? Ещё хуже.

Это типа фича.

Да и как ты статически отслеживать будешь? Вот есть в программе, скажем, преобразование i32 в u8. И что тут компилятор может увидеть? Да, в каких-то случаях, рядом будет проверка и по ней можно что-то выводить, но покажи мне кто так умеет. А ещё чаще только человек знает (и хорошо если знает, а не думает, что знает) можно ли безопасно кастовать.

Конкретно в примере со строками это, пожалуй, спорный момент. Тут обычно аргументируют тем, что будет выделение памяти и хорошо, что оно явно делается. Ну и если надо, то имеются трейты From и Into.

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

Зачем нужно шаренье ссылок? Зачем нужны ссылки? Зачем нужно владение? Зачем нужны аллокации?

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

То есть, «тупо» нельзя вернуть из функции ссылку (владеющий указатель - можно) на что-то созданное в ней же. Если, конечно, это что-то не static. Никаких аллокаций и прочего «под капотом» не происходит.

Что ты под «шареньем ссылок» подразумеваешь не знаю, если что аналог shared_ptr есть, но к ссылкам отношения не имеет. С ними тоже всё просто: на объект может быть ровно одна мутабельная ссылка и только при отсутствии обычных. И это тоже (для простых) ссылок проверяется во время компиляции. То есть нельзя «случайно» поменять объект пока кто-то ожидает, что он не изменится. Тоже всё просто и никакой магии.

Или это не то, что ты ожидал услышать и мы снова друг друга не поняли?

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

Ну людям свойственно увлекаться, почему бы и нет. Убить плюсы будет непросто, даже если убийца будет лучше по всем показателем. Но всё-таки, что в расте тебе кажется тормозным? Ну раз ты делаешь упор на «фаст».

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

Вот что является исходными данными.

Могу предложить только собственную реализацию unwrap_or.

use std::fmt::Display;
use std::borrow::Cow;

struct Struct {
    id: Option<i32>,
}

fn unwrap_or<T: Display>(opt: Option<T>, def: &str) -> Cow<str> {
    match opt {
        Some(val) => Cow::Owned(val.to_string()),
        None => Cow::Borrowed(def),
    }
}

fn main() {
    let s1 = Struct { id: None };
    let s2 = Struct { id: Some(132) };
    println!("{}, {}", unwrap_or(s1.id, "-"), unwrap_or(s2.id, "-"));
}
Ну не завезли готового сахара под этот случай.

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

Ты же не получаешь предупреждения в таких случаях:

Лично я для своего кода получаю:

source_file.cpp(9): warning C4456: declaration of 'i' hides previous local declaration
source_file.cpp(7): note: see declaration of 'i'
./test.cpp:4:13: warning: declaration shadows a local variable [-Wshadow]
        int i;
            ^
./test.cpp:2:9: note: previous declaration is here
    int i;
        ^
1 warning generated.
anonymous ()
Ответ на: комментарий от DarkEld3r

Могу предложить только собственную реализацию unwrap_or.

Спасибо, наконец-то полноценный, хоть и все-таки опять частный, аналог.

Ну не завезли готового сахара под этот случай.

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

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