&mut [MaybeUninit<*mut State>]
, инициализируете элементы и после std::mem::transmute
в &mut [*mut State]
Proxy all HTTP traffic to the passed URL.Проксирует весь HTTP трафик
Proxy all HTTPS traffic to the passed URL.Проксирует весь HTTPS трафик
Proxy all traffic to the passed URL.Пооксирует вообще весь трафик
pub fn run<T, F>(self, event_handler: F) -> Result<(), EventLoopError>
where
F: for<'a> FnMut(Event<T>, &'a EventLoopWindowTarget<T>),
{
self.event_loop.run(event_handler)
}
Я знаю, что следует избегать всяких "продвинутых" штук из ряда связных списков, самореферентных структур и т.п.Односвязные списки никаких проблем не доставляют (ну кроме того, что они плохо ложатся на процессорный кэш). Для двусвязных списков и самореферентных структур придётся использовать сырые указатели и unsafe.
Ещё я обнаружил, что создание больших структур, с методами, с кучей полей, обычно приводит к проблемам с borrow checker.Borrow checker абсолютно плевать на размер структур. Это никак не связано.
А если в структуре будет ссылка или иное заимствование, то это гарантированные проблемы.Нет ни каких проблем.
Насколько я понимаю, самым рабочим выглядит чисто функциональный подход, а не структур с методами.Одно другому никак не противоречит.
И правильно ли я понимаю, что следует избегать структур хранящих ссылки и имеющими лайфтайм?Не правильно.
Так, наличие в умеренных размерах программе, которая по сути была одной функцией, лишь одной структуры хранящей ссылку, поставило крест на попытке структуризации программы в более человеческий вид.Что-то делаете не так. Без конкретных примеров кода сказать сложно.
И очень часто в Rust программах, мне приходится идти на более уродливую архитектуру, дабы избежать проблем с (почти ненужным в однопоточном коде) borrow checker.Что-то делаете не так. Скорее всего просто не понимаете borrow checker и пытаетесь писать на новом языке так, как привыкли в каком-то другом.
И в вопросе о borrow checker, разве не является тот факт, что большинство библиотек избегает &mut self в изменяющих что-то методах, звоночком к наличию большим проблем в языке?О каком большинстве речь? Библиотеки используют мутабельные ссылки там где это нужно. Если метод действительно что-то меняет, то будет мутабельная ссылка ну и иногда будет использоваться interior mutability там где это необходимо. В языке нет проблем с мутабельными ссылками.
В общем, посоветуйте что-то что-бы помогало меньше бороться с borrow checker, потому что сейчас я очень много времени трачу именно на это.Для начала понять его. Понять какую проблему он решает. Почитайте, что такое undefined behavior. Почитайте, что такое алиасинг.
'static
.use std::cell::RefCell;
use std::rc::Rc;
#[derive(Default, Clone, Debug)]
struct NodeInner {
name: String,
source: String,
path: String,
leaf: bool,
children: Vec<Node>,
}
#[derive(Default, Clone, Debug)]
struct Node(Rc<RefCell<NodeInner>>);
impl Node {
fn fast(name: impl Into<String>, source: impl Into<String>) -> Self {
Self(Rc::new(RefCell::new(NodeInner {
name: name.into(),
source: source.into(),
path: String::new(),
leaf: true,
children: Vec::new(),
})))
}
fn insert(&self, node: Node) {
let mut current = self.clone();
for part in node.0.borrow().source.split(".") {
let inner = node.0.borrow();
let found = inner.children.iter().find(|&v| v.0.borrow().path == part);
match found {
None => {
let tmp = Node::fast(String::new(), String::new());
current.0.borrow_mut().children.push(tmp.clone());
current = tmp;
}
Some(val) => current = val.clone(),
}
}
}
}
fn main() {
let mut root = Node::default();
root.insert(Node::fast("First", "e"));
root.insert(Node::fast("First", "e.sources"));
root.insert(Node::fast("First", "e.sources.two"));
root.insert(Node::fast("First", "e.secret"));
root.insert(Node::fast("First", "e.secret.left"));
root.insert(Node::fast("First", "e.secret.right"));
print!("{:#?}", root);
}
extern C
обёртку над библиотекой и биндится уже с ней. Ну и надо понимать, что никакие абстракции плюсов вроде темплейтов, классов и т.д. в раст не протащить.fn example<'a>(r: &'a u32) -> &'a u32 { r }
fn f_a() {
let a = 1;
let r = example(&a);
}
fn f_b() {
let b = 1;
let r = example(&b);
}
В этом примере очевидно что переменная a в f_a будет иметь время жизни отличное от b в f_b, но example спокойно работает и с тем и с другим, то есть она является обобщённой по времени жизни, в первом случае она вернёт ссылку с временем жизни как у переменной a, во втором - как у b.fn make_array<const SIZE: usize>(el: u32) -> [u32; SIZE] {
[el; SIZE]
}
let arr = make_array::<3>(1); // [1, 1, 1]
Почему drop принимает ссылку, а не значение?
Причём если вызывать drop() рукамиФункция core::mem::drop никакого отношения к трейту Drop не имеет. Если Вы глянете на её реализацию, то это просто пустая функция, которая принимает аргумент по значению, а он уже дропается на общих основаниях, так как выходит из области видимости в ней.
Почему сначала вызывается drop для A, а потом для B? По логике drop должен сначала вызываться для полей.У Вас неверная логика. В метод трейта Drop приходит ссылка, а значит должна быть гарантия того что данные по ней полностью валидные. Всегда дропается сначала внешняя структура,а затем её поля. Более того компилятор не даст Вам даже мувнуть части структуры имплиментирующей Drop.
#[r]
fn bar(a: usize) -> usize {
if a % 2 == 0 {
return 0;
}
1
}
fn bar(a: usize, res: *mut usize) {
fn bar_impl(a: usize) -> usize {
if a % 2 == 0 {
return 0;
}
1
}
unsafe { *res = bar_impl(a); }
}
Главная фишка в том, что исходный код оставляем без изменений, парсить надо только сигнатуру (что с использованием syn - легко).fn main() {
let src: Vec<[u8; 1]> = (0..u8::MAX).map(|i| [i]).collect();
let mut info = Vec::<&str>::with_capacity(u8::MAX.into());
for u in &src {
let t = std::str::from_utf8(&*u).unwrap_or("Err");
info.push(t);
}
println!("\n{:#?}", info);
}
info
будет связан лайфтаймом с src
, чтоб избавится от этого нужно хранить в нём не &str
а String
или Box<str>
fn main() {
let info: Vec<Box<str>> = (0..u8::MAX).map(|i| {
let u = [i];
let t = std::str::from_utf8(&u).unwrap_or("Err");
t.into()
}).collect();
println!("\n{:#?}", info);
}
Win32_System_Threading
impl<'a> List<'a> {
fn add(&mut self, val: String, referenced_node: &'a Node) {
self.node = Some(Node {
data: String::from(String::from(val)),
next: Some(referenced_node),
});
}
}
правда скорее всего будут траблы уже в месте вызова этого метода, но что бы поправить недостаточно контекстаpub struct HashMap<K, V> {
table: Table<(K, V)>,
}
struct Table<T> {
// битовая маска занятых ячеек в items
mask: u64,
items: Box<[std::mem::MaybeUninit<Item<T>>; 64]>,
len: usize,
}
struct Item<T> {
data: T,
next: Option<std::ptr::NonNull<Item<T>>>,
}
pub enum Entry<'a, K, V> {
Vacant(VacantEntry<'a, K, V>),
Occupied(OccupiedEntry<'a, K, V>),
}
pub struct VacantEntry<'a, K, V> {
hash: u64,
key: K,
table: &'a mut Table<(K, V)>,
}
pub struct OccupiedEntry<'a, K, V> {
elem: Bucket<(K, V)>,
table: &'a mut Table<(K, V)>,
}
// указатель на Item.data
struct Bucket<T> {
ptr: std::ptr::NonNull<T>,
}
impl<K, V> HashMap<K, V> {
pub fn entry<'a>(&'a mut self, key: K) -> Entry<'a, K, V>
where
K: Eq + std::hash::Hash,
{
use std::hash::Hasher as _;
let mut hasher = self.get_hasher();
key.hash(&mut hasher);
let hash = hasher.finish();
if let Some(elem) = self.table.find(hash, |(k, _)| key == *k) {
Entry::Occupied(OccupiedEntry {
elem,
table: &mut self.table,
})
} else {
Entry::Vacant(VacantEntry {
hash,
key,
table: &mut self.table,
})
}
}
fn get_hasher(&self) -> impl std::hash::Hasher {
todo!()
}
}
impl<T> Table<T> {
fn find(&self, hash: u64, is_match: impl FnMut(&T) -> bool) -> Option<Bucket<T>> {
todo!()
}
}