Блог* – Telegram
1.93K subscribers
3.53K photos
136 videos
15 files
3.75K links
Блог со звёздочкой.

Много репостов, немножко программирования.

Небольшое прикольное комьюнити: @decltype_chat_ptr_t
Автор: @insert_reference_here
Download Telegram
Блог*
#prog #cpp #моё В C++ есть такая вещь, как strict aliasing. Если коротко, то это предположение компилятора о том, что доступы по указателям (и ссылкам) существенно разных типов не пересекаются между собой. Подробнее про это можно прочитать, например, тут…
Кстати, тот факт, что мы принимаем &[Cell<i32>], вовсе не означает, что нам нужно бегать по массивам и оборачивать элементы в Cell-ы. Можно воспользоваться двумя методами Cell:

fn into_cell_slice<T>(arr: &mut [T]) -> &[Cell<T>] {
    Cell::from_mut(arr).as_slice_of_cells()
}

Cell::from_mut работает за счёт того, что забирает переданную mut-ссылку и потому отбирает уникальный доступ до тех пор, пока возвращённая ссылка и её копии не будут дропнуты. Не смотря на то, что &Cell<T> даёт разделяемый доступ с возможностью поменять значение, это не создаёт проблем за счёт того, что изначально переданный доступ заведомо уникален, а доступ по &Cell<T> хоть и и не уникален, но заведомо находится в пределах одного потока: Cell<T> не реализует Sync, или, иными словами, ссылка на Cell не реализует Send, поэтому ссылку на Cell нельзя передать в другой поток. В рамках же одного потока доступы к одной локации в памяти никогда не происходят одновременно, и потому возможность создания гонок данных исключена.

Ну а Cell::as_slice_of_cells имеет очень простое оправдание: если мы имеем де-факто мутабельный доступ к какому-то значению, то мы можем разделить его на мутабельные доступы к его отдельным компонентам. При этом как-то подменить слайс целиком, чтобы поменять его длину, и инвалидировать ссылки на его элементы нельзя: все соответствующие методы или требуют уникальную ссылку, или работают только с Sized типами, которым слайс не является.
3👍3🔥2
Forwarded from Jem
😁16😐1
Forwarded from ЕНОТ ИЗДАЕТ
Ваша последняя книжная покупка? 👀
8
а ведь реальна блин
(кто скажет что боян тому зуб откушу)
11🤡2😁1
Forwarded from ТГ Шевченка
👍132
Forwarded from 🇺🇦 Go for two :)
The [adventofcode] just started

Happy hacking!
https://adventofcode.com/2022/day/1
🤔3👍2
Что-то в этот раз знакомых лиц значительно меньше
😭5
"TAIT — это красиво, но это nightly, у нас, например, прод на stable"

Слабаки!
🤬2
Блог*
@goldsteinq про name-it рассказывает. Интересно. Говорит, miri ругается на UB в крейте futures
#prog #rust #rustlib

Узнал про elain.

The type Align<N> is a zero-sized-type with alignment equal to N:

use elain::Align;
use core::mem::{align_of, align_of_val};

assert_eq!(align_of::<Align<1>>(), 1);
assert_eq!(align_of::<Align<2>>(), 2);
assert_eq!(align_of::<Align<4>>(), 4);

const FOO_ALIGN: usize = 8;

#[repr(C)]
struct Foo {
_align: Align<FOO_ALIGN>,
}

let foo: Foo = Foo { _align: Align::NEW };

assert_eq!(align_of_val(&foo), 8);


Valid alignments are powers of two less-than-or-equal to 2^28. Supplying an invalid alignment to Align is a type error:

use elain::Align;

struct Foo(Align<3>); // Compile Error
👍7🤔2
Мой кулинарный гений не знает границ

#rustcon2022
👍9🥴63👎2🔥2😱1🤮1
Forwarded from Backtracking (Дима Веснин)
пропустил в прошлом году и только сейчас узнал, что в MTG есть земли, целиком состоящие из текста, and i think that's beautiful
👍2🤔21
Forwarded from ozkriff.games 🦀 (ozkriff🇺🇦)
# Google: Memory Safe Languages in Android 13

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

> There are approximately 1.5 million total lines of Rust code in AOSP ... To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
> ...
> In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety.
> ...
> As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities.

/r/rust discussion
👍11