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);
}

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


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

Не может быть, тот никогда не осилит отступы и syntax highlighting.

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

Потому что забыли посмотреть в документацию, где может быть написано (если не забыли), что этот список потоконебезопасен.

Чё? А зачем ему быть «потокобезопасным»? И с чего это ему надо им быть?

А в Rust это просто не скомпилируется.

И? Уже ограничения выдают за фичи. Хотя это же основная фича куллязычков. Выпиливаем все возможности, а потом говорим что оно не сконпелировалось. Авось обыватель поверит в то, что нескомпелировалось это из-за мистических возможных ошибок который «увидел» конпелятор, а не той причине что это запрещено.

Я уже читал такие куллстори про отсутствие копирования нормального.

Так что добавьте к примеру документацию и code-reviewer'ов.

Чё?

В коде на С++ потоконебезопасность никак не отражена.

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

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

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

В коде на Rust отражена.

Мне достаточно написать «где в крестах отражена потокобезопасность» и ты съедешь с темы. Это руст так влияет, либо вера? Я не понимаю.

Так что полным аналогом это быть не может.

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

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

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

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

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

Я не понимаю - адепты раста реально думают, что запретить 70% фичей и натыкать примитивный треадсейв - этим кого-то удивишь? Натыкав тонные кастылей с абортами конпеляции во всех «небезопасных» местах, а после называть это фичей?

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

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

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

http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html

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

А, извиняюсь. race-condition не будет. Рекурсивно захватываются все мутексы.

Вот, оказывается ошибки бывают не только при работе с памятью ;) Несомненно Rust тут крут, но лично мне не нравится его многословность. В то время как современные попсовые языки делают все, чтоб ты писал меньше (причем безопасно), то Rust заставляет тебя писать:

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

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

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

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

Можно узнать, а какие конкретно кишки торчат из любого «потокобезопасного» фреймворка в С++/java/php? Мне прям интересно.

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

Никого не интересует «может» - пока не может. И лисп/хацкель уже 30лет как могут, и жабаскрипт 15лет как может и жабка может. Правда одна поправочка - в мечтах/верованиях, но не в реальном мире.

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

Если ты не приемлешь «может», то почему ты сам выкатываешь, а если приемлешь, то почему не даёшь выкатывать другим?

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

хоть и сделал прорыв в другом направлении.

А можно подробней? Давно мечтал узнать те места, в которых раст сделал «прорыв». От адептов я только слышу «может». Может «безопасной», «может компактней», «может лучше», «может быстрее». Правда пока что ни одно «может» не реализовано. Но пацаны не теряют надежды, но их надежда не может быть их аргументом.

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

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

Окей, можешь рассматривать мой пример на С++ как такую библиотеку.

Причём эффективность кода может быть выше, так как не требуется оборачивать в mutex

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

http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html

Ни о чем.

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

А можно подробней? Давно мечтал узнать те места, в которых раст сделал «прорыв»

https://doc.rust-lang.org/book/lifetimes.html

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

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

что запретить 70% фичей

Никто ничего не запрещал: unsafe, mem::transmute в руки и вперёд на грабли. А фичи в языке, вроде operator comma, или там разрешение точки с запятой после if(), или default fall thru to the next case in switch, или неявное преобразование int к bool в if(), или rvalue references с edge-cases на 10 страниц, или неявное преобразование 0 к nullptr, или отсутствие override. Ну их нафиг.

Любой школьник знает, что дорого надо переходить там, где есть знак [...] но и где указано так же может быть опасно.

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

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

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

Зачем задавать время жизни ссылок, если там есть статический анализ?

You decide to use the resource.

Как от этого можно уйти статистически? Никак. Это типа мы проставляем время жизни для тех случаев, когда оно само не выводится, продлевая его область видимости?

Чем это отличается от крестов?

Хотя если можно сделать :

f(void)  {char r[100500]; return r;}

Это полезно. Правда не ясно зачем нагорожены тонны неведомой херни.

fn bar<'a>(x: &'a i32) {

Они же вроде хотели сделать синсаксис понятней плюсов? Сколько срачей было про новые куллстори, а в конечном итоге синтаксис плюсов в который форфан понатыкано неведомо что.

Ну и про зерокост посмеялся.

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

Ну их нафиг.

С таким девизом нужно писать на Go.

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

Ответ на вопрос «зачем» - слишком сложен для тех, кто делает херню и проста для тех, кто делается что-то нужно и осмысленное.

При всем прочем - удивительно точное (хоть и двусмысленное) замечание.

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

Никто ничего не запрещал: unsafe, mem::transmute в руки и вперёд на грабли.

Такие смешные. Но ведь тогда все плюсы руста уйдут и будут кресты.

С таким же успехом я могу сказать - не юзай сишку в крестах и будет тебе safe. На кого рассчитан этот довод? На детсадовца?

А фичи в языке, вроде operator comma,

И чем тебе мешает запятая? Поподробнее. В расте её нет.

или там разрешение точки с запятой после if()

А с чего это должно быть запрещено? В расте аналога нет.

или default fall thru to the next case in switch

В расте налога нет.

или неявное преобразование int к bool в if()

А прости if(!i) не осилилось, слишком сложно if(i ===== 0) - вот он некстген.

или rvalue references с edge-cases на 10 страниц

Можно подробнее? Что конкретно тебе не нравится.

или неявное преобразование 0 к nullptr

В чём проблема. Ты не не выкатывай какую-то херню - мне на неё насрать. Ты говоришь «неявно пребразование мешает тому-то» и как это исправленно в русте.

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

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

Хотя как решение для нерадивых домохозяек покатит, но вроде как кресты язык не для домохозяек, не? С чего решения уровня домохозяек должны расценивать как решение проблемы, которая на самом деле и нет. Проблема в 99% случаев не в ножике.

или отсутствие override

Чего нет? Подробней.

Ну и замечательно.

Я не сомневался.

А в Rust дорогу можно попробовать перейти где угодно

Ты только что сознался, что в 90% мест, где её можно перейти в С++ - тебе её запретили переходить.

Почему адептов руста так влечёт бытие хомячка. Жить и дядя покормит и посадит и скажет куда надо ходить.

, в случае чего, добрый дядя компилятор вежливо скажет

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

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

что тут дорогу переходить нельзя.

Зачем? Если проще спросить и знать где можно. А не тыкаться как муха об стекло. Это как профиты от разумности - можно знать, а не тыкаться, не?

Хотя кто знает как там в вашем мире.

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

В то время как современные попсовые языки делают все, чтоб ты писал меньше (причем безопасно), то Rust заставляет тебя писать:

Справедливости ради - (далеко?) не во всех случаях раст будет многословнее.

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

Ну вот тогда. https://aturon.github.io/blog/2015/08/27/epoch/

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

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

Жить и дядя покормит и посадит и скажет куда надо ходить.

Для чего по вашему статические анализаторы, валгринды и всё такое прочее придумали? Потому-что если программистов за ручку не водить получается CVE-2016-1724, CVE-2016-1723, CVE-2016-1722, CVE-2016-1721, CVE-2016-1720, CVE-2016-1719, CVE-2016-1718, CVE-2016-1717, CVE-2016-1716, CVE-2016-1715, CVE-2016-1621, CVE-2016-1009, CVE-2016-1007, CVE-2016-1005, CVE-2016-1002 и так далее.

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

А можно подробней?

Ты просто не готов прислушиваться. Явный unsafe - это удобно, а borrow checker и лайфтаймы может и не тянут на «прорыв», но привносят дополнительные возможности/«удобства».

Любую аргументацию относительно раста можно свести к «я и в С/С++ могу (почти) так же сделать» и «такие ошибки совершают только нубы, а ещё есть валгринд, статические анализаторы и т.д.». И да, это будет более-менее правдой, но есть нюансы.

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

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

или rvalue references с edge-cases на 10 страниц

Эта фича может и не простая, но выстрелить в ногу, с её помощью, затруднительно, вроде?

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

Не увидел ничего важного и нужного.
Конечно я ничего не понял

Ok.

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

Нет.

Ну и про зерокост посмеялся.

Аргументы будут?

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

С таким девизом нужно писать на Go.

Я привёл примеры «фич», от которых вреда больше чем пользы (кроме rvalue ref). Когда вы последний раз пользовались operator comma (баги с его участием использованием не считаются), или писали if(complex_processing());//Semicolon is required here ?

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

Такие смешные. Но ведь тогда все плюсы руста уйдут и будут кресты.

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

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

На кого рассчитан этот довод? На детсадовца?

На человека, который понимает удобство автоматически проверяемых вещей.

И чем тебе мешает запятая? Поподробнее. В расте её нет.

Сначала покажи для чего ты её применяешь. Мне в голову приходят, в первую очередь, вещи типа Boost.Assignment, которые даже приводят цитату Страуструпа - " There appear to be few practical uses of operator,()." Ну так в расте это можно макросом сделать без проблем.

А с чего это должно быть запрещено? В расте аналога нет.

И хорошо что нет. Какое применение? Ну кроме внесения сложно отлавливаемых (хорошо хоть компиляторы предупреждать научились) ошибок.

В расте налога нет.

Ага, нет - оно плохо с паттерн-матчингом сочеталось бы. Хотя могли бы и сделать для «простых кейсов». Впрочем, если содержимое кейсов в функции вынести, то и «фича» не понадобится.

Ну и не даром в С++17 наконец-то сделали fallthrough атрибут.

А прости if(!i) не осилилось, слишком сложно if(i ===== 0) - вот он некстген.

Ну да, на пару символов больше пишем, зато приобретаем в читабельности. Хороший размен.

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

Когда вы последний раз пользовались operator comma (баги с его участием использованием не считаются), или писали if(complex_processing());//Semicolon is required here ?

Какая-то странная аргументация. Язык C++ развивается более 30 лет и большинство из имеющихся в нем фич появились в языке не просто так. Если вам лично эти фичи кажутся вредными, то с большой вероятностью есть люди, для которых эти фичи не просто важны, а мегаважны. Тот же operator, может быть просто незаменим где-нибудь в DSL-естроении.

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

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

Для чего по вашему статические анализаторы, валгринды и всё такое прочее придумали?

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

Потому-что если программистов за ручку не водить получается

Это не проблема программистов - это проблема подхода. Это излюбленный подход ремонта дорог в рашке, да и всего остального.

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

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

CVE

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

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

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

99% этих ошибок - это ошибки в самой логике программы, которые никакие расты/ жабки их не то что не исправляют, а даже не способствуют этому, а наоборот.

Какая разница - адепт нейчайно послал приваткей перепутав что-то при копипасте, либо перепутал и отправил кусок хипа.

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

Жабка решает проблемы безопасности, как и любой bounds check, но создаёт абсолютно неюзабельные реализации. Как альтернативу сишному/крестовому рантайму никто не написал - так и не напишет. Как был дырявый опенссл - там и остался.

Хотя это всё протухшее легаси и современный раст соревнутся с сишным кодом из 70-х, но бывает - адептам это не надо знать.

Ну и самое главное - ответ никак не вытекает из приведённой моей цитаты. Помощь это не замена мозга. Самопроверка и дополнительная проверка - не замена мозга.

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

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

Явный unsafe - это удобно, а borrow checker и лайфтаймы может и не тянут на «прорыв», но привносят дополнительные возможности/«удобства».

Кому?

Ещё раз - раст пиарится как быстрый safe, который такой же мощный/быстрый как кресты, но более safe. В конечном итоге это всё - от первого до последнего слова - брехня.

Любую аргументацию относительно раста можно свести к «я и в С/С++ могу (почти) так же сделать» и «такие ошибки совершают только нубы

Это работает. Этого достаточно.

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

Неюзабельно и не нужно.

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

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

Одно дело, что тебе нравится, а другое дело соответствие «заявляемое/реальность», да и минимальная, объективная нужность. Если ты не заметил - я хейтер крестов и плювал в них, но как бы крестовику ничего сказать против нельзя - почти всё в крестах нужно для рядового гуйняваятеля.

Раст же ничего, кроме балабольства, из себя не представляет. Тебе нравится? Молодец. Я не говорю тебе не юзать то, что тебе нравится, но когда разговор заходит об холиварах - твоё «нравится» мало кому интересно.

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

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

Ты споришь с царем сишки. Воспринимать его всерьез - ошибка.

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

это ошибки в самой логике программы, которые никакие расты/ жабки их не то что не исправляют,

Если бы вы интересовались фактами, а не умствовали вспустую, то заметили бы, что все CVE, которые я привёл, вызваны memory corruption, защиту от которого Rust гарантирует. Прощайте.

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

Смешные как раз такие аргументы. В плюсах постарались сделать некоторые тонкие места С менее опасными - да хотя бы касты.

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

При этом сишный каст тоже имеется, но ведь тебя это не смущает.

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

Сишный каст ничем не отличается от статик-каста, а другие касты не по этой части.

Опять же, есть asm (в расте тоже, кстати) с которым много чего наворотить можно.

Абсолютно бесполезен. И кто на нём в расте будет что воротить? Никто. Там уже зависимость от libc ушла?

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

Это не поможет. Код писать либо дано, либо не дано.

На человека, который понимает удобство автоматически проверяемых вещей.

В мире радужных пони - возможно. И что конкретно проверяет раст? Ничего.

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

Сначала покажи для чего ты её применяешь. Мне в голову приходят, в первую очередь, вещи типа Boost.Assignment, которые даже приводят цитату Страуструпа - " There appear to be few practical uses of operator,()." Ну так в расте это можно макросом сделать без проблем.

Везде. do{} while(++a, ++b != c) return f(a), f(b), f(c);

И хорошо что нет. Какое применение? Ну кроме внесения сложно отлавливаемых (хорошо хоть компиляторы предупреждать научились) ошибок.

Не помню чтобы как-то пригождались, но и не понимаю каким там могут быть «ошибки»?

Наверное уровня if(a = b)? Надо и присваивание в ифах запретить. Хотя вр асте 100% запрещено.

И? Какая-то логика странная. А после цикла точка с запятой уже ошибок не вызвает? Если ты собрался выпиливать - выпиливай всё.

Ну да, на пару символов больше пишем, зато приобретаем в читабельности. Хороший размен.

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

Чем if(!i) менее читаемый, чем if(i ====== 0) - мне не ясно. Адепт не знает оператор !? Или после жабки сложно понять ненужность була?

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

memory corruption

Вызвана только ошибка в логике. И когда адептам уже вобьют в их «голову» разницу между устранением ошибки и последствием её, в частности мистическим «memory corruption».

Ошибка никуда не делать. И раст её никак не исправит. И я там не зря написал про bounds check и почему он не юзабельный. А рассуждать об «ошибки бы не было» - смешно. Не было - сходи перепиши на раст, а лучше на жабку. Не смог ни ты, ни любые другие адепты, тогда о чём заговор? Одно балабольство.

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

Ok.

Проблема в том, что моё понимание намного сильнее, скажем так, среднестатистического обывателя.

Поэтому я задам тебе вопрос - ты понял - расскажи «зачем».

Нет.

А для чего?

Аргументы будут?

Аргументы этот как? Как бэ я по определению знаю «зерекост» оно или нет, ибо я ходячий зерокост. Мы можем поиграться, если ты хочешь конкретные пруфцы.

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

Здесь ещё кто-то может со мною спорить? Вот это новость. Хотя в вас верю, лапочки ^_^ - вы сможете, ня.

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

то фич в него еще понапихают.

Да собственно уже пихают.

большинство из имеющихся в нем фич появились в языке не просто

Да, но у этого есть и обратная сторона: многие фичи - это исправление принятых ранее решений. Например, overload и fallthrough. То есть неявный fallthrough, по сути, признают не самым удачным решением, но «исправить» уже нельзя из-за обратной совместимости - остаются «полумеры» типа предупреждений. Конечно, я соглашусь, что лучше так, чем никак и что ломать совместимость плохо. Но новые языки могут сразу учесть чужой опыт.

Но всё-таки - можешь придумать хоть одно применение точки запятой после тела if? Даже если да, то мне всё равно кажется более правильным сделать обязательное тело, которое может быть и пустым. В последнем случае, хотя бы будет явно видно, что это сознательно решение, то есть возможность так сделать даже не теряется.

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

Я задам один вопрос «зачем» и на каком-то шаге ты в любом случае поплывёшь.

Скажи честно - тебе собственная аргументация кажется логичной? Ты же спокойно игнорируешь половину, а остальное передёргиваешь как удобно.

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

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

Сишный каст ничем не отличается от статик-каста

Да ладно?

Абсолютно бесполезен. И кто на нём в расте будет что воротить? Никто.

Не соответствует действительности.

Везде. do{} while(++a, ++b != c) return f(a), f(b), f(c);

И какие сложности переписать это нормальным образом? Особенно return.

Не помню чтобы как-то пригождались, но и не понимаю каким там могут быть «ошибки»?

if (...);
{
    ...
}

А после цикла точка с запятой уже ошибок не вызвает?

Ну приведи пример когда будет вызывать.

Критерий читаемости кода только один - компактность и лаконичность.

Нет. Иначе записывание «в одну строчку» и однобуквенные переменные были бы везде.

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

Аргументы этот как?

Это так. Покажи какую стоимость имеют лайфтаймы.

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

Скажи честно - тебе собственная аргументация кажется логичной? Ты же спокойно игнорируешь половину, а остальное передёргиваешь как удобно.

Я ожидал больше. Поплыл ещё до первого шага.

Почему так трудно ответить на вопрос «зачем»? Что конкретно я игнорирую? Приведи пример.

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

Подожди, почему когда ты спрашиваешь «зачем запятая» - я объясняю. Привожу примеры и прочее, а когда тебя спрашивают «зачем» - ты ничего не приводишь - это как?

Пытаюсь я тебя понять максимально сильно, но какие-то рамки приличия надо соблюдать.

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

Нет. Иначе записывание «в одну строчку» и однобуквенные переменные были бы везде.

Ты путаешь «записывание «в одну строчку» и однобуквенные переменные» с компактностью и лаконичностью.

Например в Swift мы пишем:


А в Rust пишем:

println!( "{}", c.tel.unwrap_or( "None".to_owned() ) );

Код одинаково безопасный, но читается и пишется по разному.

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

Ух ты, парсер ЛОР-а сломался, в общем там пропущено:

print( c.tel ?? «None» )

на Swift.

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

Но всё-таки - можешь придумать хоть одно применение точки запятой после тела if?

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

if(something)
  then_action();
else
  else_action();
В процессе отладки захотелось закомментировать then_action, поэтому сделали просто:
if(something)
  ;//then_action();
else
  else_action();
Лично мне не понятно, чем здесь ; хуже, чем {}.

Ну и из этой же оперы. Время от времени доводилось писать что-то вроде:

while("exit"!=read_next_line())
  ;
Не вижу причин, почему это сильно хуже, чем вот это:
while("exit"!=read_next_line())
  {}
И если тело while можно представлять в виде одной точки с запятой, то почему нельзя того же делать с if-ом?

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

Ну так покажешь, какова стоимость лайфтаймов, или как обычно?

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

Да ладно?

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

Не соответствует действительности.

Ты мне про либц ответь. Это очень важно. Да и что конкретно не соответствует действительности? Ты мне можешь показать как там пацаны юзают асм? Самый простой пруфец, который раст-адепты могут предоставить про компетентность и юзабельность асма и лоулевел в расте - libc, что-то в районе string и иже с ним.

И какие сложности переписать это нормальным образом? Особенно return.

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

if (...) {//ставь нормальный скобки.
    ...
}

Я не спрашивал про ошибки всмысле как реализовать эту обишку - я итак знаю. Я спрашивал про «как там может взяться эта ошибка?». Я не понимаю каким образом там может взяться ошибка.

Ну приведи пример когда будет вызывать.

while (...);
 {
    ...
}

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

Нет.

Да.

Иначе записывание «в одну строчку» и однобуквенные переменные были бы везде.

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

Одна строчка никак не следует из компактности - строчка пишет там, где она пишется и где её следует писать.

Однобуквенные переменные неюзабельны, ибо их слишком мало. Да и в компактность никак не входят однобуквенные переменные. Компактность подразумевает отсутствие избыточности, а не обфускацию.

Меня всегда удивляли эти куллстори - люди тысячи лет читают однострочники, а тут вдруг гении решили, что однострочники не читаемы. Тысячи лет на уроках учат арифметические выражения-однострочки на сотни сиволов.

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

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

Rust has a focus on safety and speed. It accomplishes these goals through many ‘zero-cost abstractions’, which means that in Rust, abstractions cost as little as possible in order to make them work. The ownership system is a prime example of a zero-cost abstraction.

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

А вообще - в любом случае ты сольёшься на кресты или ещё какую-помойку с лайфтаймам-объектами - где то же самое.

Мне лень тебе лсу объяснять в чём проблема - ты всё равно не моймёшь. Я могу тебе показать. - выкатывай юзкейс посоревнуемся - покажешь мне зерокост.

Тем более выше писал, что:

I lend you a reference to the resource.
I decide I’m done with the resource, and deallocate it, while you still have your reference.
You decide to use the resource.

Не реализуется в компилтайме никак.

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

Хотя нет, я даже подыиграл Rust'у.

struct Customer {
    let tel: Int?
}

let c = Customer( tel: 12345678 )
print( c.tel ?? "None" )

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

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

.unwrap_or
to_owned

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

!
println
fn

Всё делает для того, чтобы отличатся от си. Но что-то с синтаксисом не фортануло.

«{}»

2016год - мы сделали принтф образца 70-х. Мощно.

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

Ну так покажешь, какова стоимость лайфтаймов, или как обычно?

Мне лень тебе лсу объяснять в чём проблема - ты всё равно не моймёшь.

Значит, как обычно.

выкатывай юзкейс посоревнуемся - покажешь мне зерокост.

Сейчас доиграю с голубем партию в шахматы, а потом с тобой в зерокост.

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

Я всё выше написал. Балаболить смысла нет с теми у кого понимание уровня домохозяйки и объяснять им что-то бессмысленно. Если осилишь послушать и выкатить примеры - я тебе даже объясню.

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

Пытаюсь я тебя понять максимально сильно, но какие-то рамки приличия надо соблюдать.

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

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

Ещё раз - раст пиарится как быстрый safe, который такой же мощный/быстрый как кресты, но более safe. В конечном итоге это всё - от первого до последнего слова - брехня.

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

Ничего не увидел из того, что относится к языку.

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

DarkEld3r ★★★★★ ()
Ответ на: комментарий от anonymous
println!( "{}", c.tel.unwrap_or( "None".to_owned() ) );

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

println!("{:?}", c.tel);

Ты путаешь «записывание «в одну строчку» и однобуквенные переменные» с компактностью и лаконичностью.

Я как раз не путаю.

DarkEld3r ★★★★★ ()
Последнее исправление: DarkEld3r (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.