LINUX.ORG.RU

Rust и типобезопасность

 ,


3

7

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

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

Почитав документацию:

The as keyword does safe casting

Набросал такой примерчик:

fn main() {
        let a: f64 = std::f64::MAX;  // данное значение просто пример "большого числа"
        let b = a as i64;
        println!("{}", b);
}

Вопросы:

1) С какой стати это вообще компилируется?

2) Да, f64 и i64 нужно одно и то же количество битов для хранения значения, ну и что?

3) Почему результат меняет знак?

Представьте, что какой-то тех. процесс идет, и определенный параметр нельзя изменять скачкообразно, иначе физически система (по крайней мере, один из компонентов) выйдет из строя (встанет в раскоряку, взорвется, выпустит токсичный газ, убивающий 100тыс. населения; нужное подчеркнуть). И вот значение в f64 положительное и увеличивается постепенно, с i64 все вроде в порядке (и тестирование проходит на тестовых значениях), и вдруг хренак! и уже -9223372036854775808

Как так?

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

почему вы используете раст?

Потому, что для моих задач он лучше всего подходит. Ваш КО.

Мне нужна макс. производительность, при этом Сишка слишком убога, а плюсы слишком переусложнены и на них будет намного сложнее писать. Ну и UB, куда же без него. Другие языки мне в принципе не подходят, ибо GC.

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

почему вам обязательно надо доказать что это так

Это не научная дискуссия. Я сюда поржать пришёл.

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

То есть, пошел переход на личности

Вот это:

Увы, это просто ужас-ужас-ужас, а не концепты. Смешно, будто бы код с концептами C++20 понять проще! Причем человеку, который успел довольно плотно поработать с C++, эпизодически, но очень плотно.

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

а по существу вопроса ответить нечего.

По существу чего?

Вот у меня есть впечатление, что вы на C++ эпизодически пытаетесь писать как на Haskell-е или как на каком-нибудь Lisp-е. Отсюда и ваша боль.

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

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

в стд нет рандома

И на то есть множество веских причин. Посмотрите сколько всего пришлёт затащить в C++ std ради этого (я надеюсь мы с вами не про rand() сейчас).

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

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

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

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

Это не сишка, где нужно пердолится с системами сборки.

И это на самом деле круто.

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

Чего в стандартной плюсовой библиотбиблиотеке есть такого чего нет в расте?

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

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

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

Ничего личного, но ты первый начал нести чушь.

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

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

void f(T)(T value) if (is(T == int)){
    value.writeln;
}
SR_team ★★★★★
()
Ответ на: комментарий от RazrFalcon

Я и не утверждал обратное.

Ок, принято.

И в расте ограничение идёт по трейтам, а не по типам.

Типы используются в приведенном мной примере и типами в D тоже все не ограничено.

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

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

А мне кажется, что С++ и Rust достаточно похожие языки…

https://imgur.com/a/zwYYHfA

https://youtu.be/olM7o_oYML0

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

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

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

Ну так-то и conan есть, вот только они не стандартные и поддерживают не все. Нет единого способа оформлять код на С++.

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

Дополню комментарий мнением царя на этот пример, а то тред закрыли от анонов :(

https://imgur.com/a/DM1yIHQ

Ну и повторюсь, на С++ можно писать по разному, но если хочется как на Rust, то получается по-моему довольно похоже…

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

Ну так-то и conan есть

Там ничего нет, и никому он не нужен. В vcpkg есть практически все (попробуй дать 3 либы которых нету), он интегрируется с visual studio, cmake.

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

Вы видимо в какой-то || реальности живёте ^_^

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

Ахахаха )) А может не из раста а в принципе из парадигм программирования, отвязанных от любого языка? ))

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

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

На C++, возможно, можно сварганить что-то подобное на шаблонах (и я это делаю для себя), но сильно увеличивается сложность восприятия и сложность поддержки кода. Например, написал шаблон, он откомпилировался, но ты не знаешь, правильно ли ты написал шаблон, пока ты его везде не применил там, где это тебе нужно было. Многие ограничения ты должен держать в уме, и лишь компилятор ругнется только при инстанциировании, если ты что-то сделал не так, но ты еще попробуй пойми, что тебе хотел сказать компилятор в своей двадцатистраничной простыне. Для сравнения (на мой часный взгляд, чтобы не приставали надоедливые мухи, воображающие себя экспертами) в растишке проверяется гороздо больше, и сообщения там гораздо более конкретные. И да, это пока без учета концептов, но мне кажется, что с ними сильно намудрили.

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

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

vcpkg

Вот прям щас поставил и запустил ./vcpkg install matio - получил ошибку сборки matio (зависимости нормально скомпилировались) :) Вывод - выглядит «вкусно», а на деле пока не пригодно для нормального использования.

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

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

У меня и cargo постоянно ошибками сыплет. Да в принципе все что умеет собирать из исходников постоянно ломается. И pip'ы всякие... cpan'ы.

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

У меня и cargo постоянно ошибками сыплет.

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

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

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

Ни разу не видел такого, интересно стало :)

Ну я и фейлов сборки vcpkg не видел. Сейчас специально собрал matio, и ведь собралось. Но все что собирается из исходников обреченно на фейлы сборки.

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

Сейчас специально собрал matio, и ведь собралось

На какой ОС и какие версии компилятора и vcpkg (я пробовал последний релиз + git)?

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

Windows 10, vcpkg 2020.02.04, Visual Studio 2019

Понятно :) Я потыкал их Issues на гитхабе, возникло стойкое ощущение, что более-менее тестируют пакеты на винде, а остальные ОС по остаточному принципу. По-хорошему, им бы надо поднять билд-сервера под популярные ОСи и прогонять пакеты на них перед пушем в основную репу.

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

Понятно :) Я потыкал их Issues на гитхабе, возникло стойкое ощущение, что более-менее тестируют пакеты на винде, а остальные ОС по остаточному принципу.

Ну лол, это же не Microsoft все пакеты добавил и тестирует.

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

Было бы хорошо, но это надо собирать под разные версии компиляторов, стандартных библиотек, плюс там же можно выбирать опциональные зависимости, под каждую ОС есть так же x86, x64, x86-static, x64-static... Ну Microsoft наверное может себе позволить в принципе.

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

Ну лол, это же не Microsoft все пакеты добавил и тестирует.

Это-то понятно :) Но они, вроде как, кросс-платформенность заявляют

Было бы хорошо, но это надо собирать под разные версии компиляторов, стандартных библиотек, плюс там же можно выбирать опциональные зависимости, под каждую ОС есть так же x86, x64, x86-static, x64-static… Ну Microsoft наверное может себе позволить в принципе.

МС с их ресурсами точно это может себе позволить :) Тем более не нужно прям все комбинации тестить, достаточно основные ОСи добавить типа RHEL/CentOS, SUSE, Debian, Ubuntu LTS… Если на них будет собираться, то и на остальных с высокой вероятность всё будет ОК.

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

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

struct DynShape {
  virtual double area() const = 0;
  virtual double perimeter() const = 0;
  friend auto area_per_perimeter(const DynShape& shape) {
    return shape.area() / shape.perimeter();
  };
  virtual ~DynShape() {}
};

, и все.

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

В nightly с saturation arithmetic просто будет выводить: […]

Если это с тем же синтаксисом «x as y» будет автоматом насыщенная арифметика, то это не то. Вернее так. На базовом уровне, когда явно не указывается, что нужно saturation arithmetic, логично было бы либо вообще запретить использование небезопасных конверсий, либо кидать исключение в рантайме только при операциях с переполнением (как делает Ada, и при данном подходе бонусом будет, что на этапе юнит тестирования уже будет видно, что блок исключения не покрыт тестом). А saturation arithmetic все же достаточно сложная операция, чтобы указывать ее использование в коде явно.

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

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

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

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

Как бы в C++ полиморфность можно реализовать и на обычном ООП. И, в простых случаях, вообще на перегрузке функций/методов под нужные типы параметров.

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

Короче, это сложно описать без примеров, а подходящих для ЛОРа примеров у меня нет (нафиг не сдалось тут что-то такое писать).

«У нас есть такие приборы, но мы их вам не покажем» (с)

А тот, кто смеет не верить некому @dave с LOR-а на слово, тот «надоедливая муха» и «типа эксперт», поэтом разговаривать с ним не о чем.

Позвольте у вас спросить @dave, который хз кто хз откуда, т.к. в вашем профиле о вас ничего нет: как можно узнать что вы вообще программировать умеете? По крайней мере на С++.

Ну вот не сочтите это за наезд, а просто подумайте сами: откуда?

Или может на LOR-е теперь принято верить на слово? Типа поверим на слово RazrFalcon-у что в C++20 включают фичи из Rust-а. И еще больше поверим хрюнделю, который утверждает, что RazrFalcon ничего подобного не говорил (а ведь он говорил).

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

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

Концептов не пробовали, но они «ужас-ужас-ужас». Пастернака не читал, но осуждаю.

Ужас-ужас-ужас – это пятиэтажные SFINAE в коде. Или надобрость писать static_assert-ы в обобщенных функциях чтобы как можно раньше диагностировать несоответствие типов.

Вряд ли вы с этими настоящим ужасами сталкивались, поэтому для вас концепты, которые все это приводят в норму, выглядят как «ужас-ужас-ужас».

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

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

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

Как бы в C++ полиморфность можно реализовать и на обычном ООП. И, в простых случаях, вообще на перегрузке функций/методов под нужные типы параметров.

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

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

В контексте генериков я применил самое подходящее значение для этого термина, а именно то, как это принято в хаскеле

Повторю то, что уже говорил раньше:

Вот у меня есть впечатление, что вы на C++ эпизодически пытаетесь писать как на Haskell-е или как на каком-нибудь Lisp-е. Отсюда и ваша боль.

С++ – это С++, не Haskell, не Rust, ни Common Lisp. На C++ нужно программировать как на C++.

Но вы, видимо, пытаетесь делать это как вам привычнее из Haskell-я.

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

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

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

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

Евгений, вы тут тоже хороши, на самом деле. Вы регулярно включаете снисходительно-вежливый старперский стиль, который многим (осознанно или инстинктивно) не нравится. Я понимаю, что вам, скорее всего, больше лет, чем многим тут, но не надо тупо «давить авторитетом» и намекать оппоненту, что он лох с С++, т.к. лично вы его код не видели. Я вот ваш код видел и не могу сказать, что в восторге :)

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

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

С таким подходом std окажется пуста, ибо любая вещь нужна далеко не в каждой программе

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

он лох с С++

Сказать, лох ли он в C++ или нет формально нельзя. Речь о том что он лох в общении

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

плебея от царя я как-нибудь переживу, чай не обидчивый

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

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

Сам такого не видел, но если это имеет место быть, то ничего хорошего, конечно.

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

Я вот ваш код видел и не могу сказать, что в восторге :)

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

Или вот взять RazrFalcon. Я понимаю, как относиться к его словам про C++. При этом я видел его Rust-овский код. И когда RazrFalcon говорит что-то про Rust, то у меня нет оснований не воспринимать его мнение всерьез. Возможно, с чем-то я буду несогласен, но точно буду знать, что под сказанным есть основание. Хорошое такое основание.

Тогда как со словами dave непонятно что делать. Сразу в /dev/null или же посчитать что в них есть рациональное зерно.

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