Э
Потому что в контракте строки не сказано что она _обязана_ быть хип аллокейтед. Значит это деталь реализации, писать код с потенциальным уб с оглядкой на текущую реализацию - хрень
This buffer is always stored on the heap.
Size: a a a
2020 March 24
Э
std::string::String.html#Representation
AZ
This buffer is always stored on the heap.
окей, раньше там этого не припомню
AZ
red75prime
Если в вектор только пушим, то UB не будет. Со ссылкой мы можем получить UB на ровном месте:
наша_типа_статическая_str.ptr_eq(&vec[0])ок
D
(напоминаю, что Rc/Arc/Box<str> занимает меньше места, чем String)
Э
(напоминаю, что Rc/Arc/Box<str> занимает меньше места, чем String)
Rc/Arc - нет.
struct RcBox<T: ?Sized> {
strong: Cell<usize>,
weak: Cell<usize>,
value: T,
}
pub struct Rc<T: ?Sized> {
ptr: NonNull<RcBox<T>>,
phantom: PhantomData<RcBox<T>>,
}
struct RcBox<T: ?Sized> {
strong: Cell<usize>,
weak: Cell<usize>,
value: T,
}
pub struct Rc<T: ?Sized> {
ptr: NonNull<RcBox<T>>,
phantom: PhantomData<RcBox<T>>,
}
D
Rc/Arc - нет.
struct RcBox<T: ?Sized> {
strong: Cell<usize>,
weak: Cell<usize>,
value: T,
}
pub struct Rc<T: ?Sized> {
ptr: NonNull<RcBox<T>>,
phantom: PhantomData<RcBox<T>>,
}
struct RcBox<T: ?Sized> {
strong: Cell<usize>,
weak: Cell<usize>,
value: T,
}
pub struct Rc<T: ?Sized> {
ptr: NonNull<RcBox<T>>,
phantom: PhantomData<RcBox<T>>,
}
я же скинул ссылку на плейграунд, ну
Э
Ты видишь, что Rc<str> в реальности занимает четыре usize?
Э
Nonnull на !Sized структуру - два юсайза, плюс внутри структуры два.
В
этого нет в апи, значит на такое поведение рассчитывать нельзя
Ты путаешь стирание байтов и вызов Drop. Если бы вектор дропал элементы при реаллокации, это был бы уб. (В плане если бы он из дропал а потом перемещал)
AZ
Ты путаешь стирание байтов и вызов Drop. Если бы вектор дропал элементы при реаллокации, это был бы уб. (В плане если бы он из дропал а потом перемещал)
я говорил про "сначла скопировал, а потом удалил"
В
я говорил про "сначла скопировал, а потом удалил"
Αλεχ Zhukovsky, [24.03.20 13:59]
ничто не мешает вектору скопировать строку в новое место при аллокации и вызвать дроп на старой
ничто не мешает вектору скопировать строку в новое место при аллокации и вызвать дроп на старой
AZ
Αλεχ Zhukovsky, [24.03.20 13:59]
ничто не мешает вектору скопировать строку в новое место при аллокации и вызвать дроп на старой
ничто не мешает вектору скопировать строку в новое место при аллокации и вызвать дроп на старой
"и" надо читать как "и после этого"
В
"и" надо читать как "и после этого"
Всё равно, не любые данные валидно копировать
Э
И не любой дроп валидно вызывать.
Э
Можно было бы заморочиться специализацией, но здравый смысл против лишних переаллокаций.
AZ
Всё равно, не любые данные валидно копировать
я не про любые говорил, а про строки. Компилятор может спокойно специально генерировать код для случая вектора строк
В
я не про любые говорил, а про строки. Компилятор может спокойно специально генерировать код для случая вектора строк
Ок, справедливо
Э
red75prime
Если в вектор только пушим, то UB не будет. Со ссылкой мы можем получить UB на ровном месте:
наша_типа_статическая_str.ptr_eq(&vec[0])Так, я прогнал код через MIRI, она не ругается. Стоит ли всё же делать указатель вместо 'static str?
Э
Ну то есть, стоит ли оно того, чтобы перебороть свою лень?