Так, а что тут не так? И почему не совпадают типы?
Дело в том, что у каждой функции — не только у замыканий — в Rust свой собственный уникальный тип. Здесь мы попытались сохранить значения двух разных типов в паре одинаковых типов, поэтому наш код не компилируется.
Зачем так сложно? В этом же нет никакого смысла!
Вообще-то есть. Компилятор эксплуатирует тот факт, что тип населён единственным значением, и потому не хранит и не передаёт адрес функции, а вставляет его по месту вызова. Таким образом, компилятору предоставляется больше возможностей для встраивания (inlining) функций. Также это влияет на структуры, которые хранят в себе функции: если тип не указан явно как функциональный указатель, обычная функция вообще не занимает места в памяти. Функциональный указатель же занимает столько же места, сколько и указатель:
Просто хранить разнородную пару.
А если нам принципиально, чтобы элементы пары имели одинаковый тип?
В таком случае нам надо привести значения к одинаковому типу. Это можно сделать так:
А вот про это я расскажу в следующий раз.
Дело в том, что у каждой функции — не только у замыканий — в Rust свой собственный уникальный тип. Здесь мы попытались сохранить значения двух разных типов в паре одинаковых типов, поэтому наш код не компилируется.
Зачем так сложно? В этом же нет никакого смысла!
Вообще-то есть. Компилятор эксплуатирует тот факт, что тип населён единственным значением, и потому не хранит и не передаёт адрес функции, а вставляет его по месту вызова. Таким образом, компилятору предоставляется больше возможностей для встраивания (inlining) функций. Также это влияет на структуры, которые хранят в себе функции: если тип не указан явно как функциональный указатель, обычная функция вообще не занимает места в памяти. Функциональный указатель же занимает столько же места, сколько и указатель:
fn main() {Кстати, на замыкания это тоже распространяется: значение замыкания хранит в себе только захваченные данные, поэтому размер замыкания равен (с поправкой на выравнивание) размеру захваченных данных. Если замыкание ничего не захватывает, то у него нулевой размер:
assert_eq!(std::mem::size_of_val(&add_one), 0);
let add_one_ptr: fn(u32) -> u32 = add_one;
assert_eq!(
std::mem::size_of_val(&add_one_ptr),
std::mem::size_of::<usize>()
);
}
fn main() {Теперь я вижу, что в этом действительно есть смысл. И всё-таки, как скомпилировать тот пример с парой функций?
assert_eq!(std::mem::size_of_val(&|x: u32| x + 1), 0);
}
Просто хранить разнородную пару.
А если нам принципиально, чтобы элементы пары имели одинаковый тип?
В таком случае нам надо привести значения к одинаковому типу. Это можно сделать так:
let funcs: Pair<fn(_) -> _> = (add_one, add_two);Обратите внимание, выписывать тип точно в этом случае не нужно, достаточно сказать, что это function pointer. Другой способ — явно привести одно из значений в паре:
let funcs: Pair<_> = (add_one as fn(_) -> _, add_two);Второе значение будет неявно приведено (coerced) к нужному типу. В принципе, ничто не мешает написать явный каст у обоих значений, но надобности в этом в данном примере нет. Кстати, если мы сделаем массив функций, то никаких кастов делать не придётся, rustc сам уравняет типы до функционального указателя:
let arr = [add_one, add_two];А что, если замыкание возвращает захваченное значение? Если это значение не копируемо, то замыкание можно вызвать только один раз...
А вот про это я расскажу в следующий раз.
#prog #amazingopensource
Если вы когда-нибудь хотели сделать свой блог, но не знали, как сделать комментарии (или не хотели подключать жирный Disqus), то этот вариант может подойти: комментарии, работающие поверх issue в GitHub.
utteranc.es
Если вы когда-нибудь хотели сделать свой блог, но не знали, как сделать комментарии (или не хотели подключать жирный Disqus), то этот вариант может подойти: комментарии, работающие поверх issue в GitHub.
utteranc.es
Forwarded from мне не нравится реальность
Есть некоторое http-api. Я пишу для него враппер на расте. В апи один из параметров метода — число от 1 до 100000. Вопрос: как лучше отобразить отобразить этот параметр в либе?
Final Results
27%
u32
3%
NonZeroU32
63%
new-type который будет проверять что он >= 1 && <= 100000
8%
(свой вариант)
#blogrecommendation
Человек пишет на Rust... Много всего. В частности, недетерминированный парсер для естественного языка — и это его дипломная работа. Если честно, я даже немного завидую его продуктивности.
t.iss.one/optozorax_dev/184
Человек пишет на Rust... Много всего. В частности, недетерминированный парсер для естественного языка — и это его дипломная работа. Если честно, я даже немного завидую его продуктивности.
t.iss.one/optozorax_dev/184
Telegram
dev optozorax
А мой парсер всё обрастает возможностями. Теперь можно задавать как будут изменяться "вероятности" распаршенного правила.
UPD: это скорее не вероятности, а веса.
Мы всё-же парсим естественный язык достаточно приближённо, значит некоторые конструкции весьма…
UPD: это скорее не вероятности, а веса.
Мы всё-же парсим естественный язык достаточно приближённо, значит некоторые конструкции весьма…
Forwarded from red75prime
unsafe не значит, что там что-то не так. Это значит, что мы знаем что-то, что не знает компилятор. Или думаем, что знаем
#prog #article
Реальность такова, что среди существующих программ полно уязвимых, допускающих использование в злонамеренных целях. Огромное количество подобных уязвимостей проистекает из некорректного парсинга входных данных. Конечно, легко сказать: "Эй, программисты, будьте внимательнее", но практика показывает, что подобный метод работает довольно фигово. В данной статье перечислены основные проблемы, возникающие при обработке входных данных, вместе с более-менее конкретными указаниями на то, как их исправить.
https://langsec.org/papers/langsec-cwes-secdev2016.pdf
Реальность такова, что среди существующих программ полно уязвимых, допускающих использование в злонамеренных целях. Огромное количество подобных уязвимостей проистекает из некорректного парсинга входных данных. Конечно, легко сказать: "Эй, программисты, будьте внимательнее", но практика показывает, что подобный метод работает довольно фигово. В данной статье перечислены основные проблемы, возникающие при обработке входных данных, вместе с более-менее конкретными указаниями на то, как их исправить.
https://langsec.org/papers/langsec-cwes-secdev2016.pdf
#prog #rust #article
Недавно в Rust-сообществе поднялся шум по поводу недавней статьилодочника WithoutBoats, в которой он приводит аргументы за автоматическое оборачивание в
Недавно в Rust-сообществе поднялся шум по поводу недавней статьи
Ok
значений, возвращаемых из функций с типом возврата Result
. В ней представлены несколько аргументов "за" различной степени убедительности и опровергнуты несколько откровенно слабых аргументов "против". Один из ответов на эту статью — Mental models about Ok-Wrapping, в которой приведены реальные сложности, которые могут возникнуть с на практике с подобной реализацией.Всем известно, что антиква (шрифты с засечками) читается лучше, чем гротеск (шрифты без засечек). Ведь так? Так?
Ну, не совсем. Или даже совсем не. Разбирается на хабре Юлия Кондратьева.
habr.com/ru/company/tinkoff/blog/498878/
#article и пусть будет новый хештег, скажем... #design
Ну, не совсем. Или даже совсем не. Разбирается на хабре Юлия Кондратьева.
habr.com/ru/company/tinkoff/blog/498878/
#article и пусть будет новый хештег, скажем... #design
Хабр
Знаменитые дизайнеры vs научные исследования про читаемость шрифтов
Я работаю дизайнером около 10 лет. В дизайне не очень много объективных и проверяемых законов, и когда мне нужно было что-то выяснить, я искала информацию в профессиональных книгах, блогах крутых...