Как создать самореферентную структуру?

Это один из случаев, когда String::leak может быть уместным. Это потребляет String (не освобождая принадлежащее ему распределение кучи) и возвращает ссылку на фрагмент всей строки, но со временем жизни 'static.

pub fn read_file_and_analyze_fast(file_name: &str) -> Vec<&'static str> {
    let content = std::fs::read_to_string(file_name)
        .expect("Could not read the file you told me to analyze")
        .leak();

    let lines: Vec<&str> = content.split("\n").collect();

    lines
}

Обратите внимание, что я изменил тип возвращаемого значения на Vec<&'static str>, чтобы было понятно, что фрагменты строк, содержащиеся в Vec, имеют время жизни 'static. Если вы не измените это, они будут ограничены тем же временем жизни, что и ссылка на входной фрагмент file_name (что также может быть 'static, но здесь это не имеет особого значения).

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

Другой подход, поскольку входной файл каждый раз будет одним и тем же, — использовать include_str!, который представляет собой макрос, который расширяется до &'static str, полученного путем чтения содержимого указанного имени файла во время компиляции. (Это то, что я делал, когда работал над Advent of Code.)

Если вы одержимы самореферентной структурой данных, со строками это безопасно, поскольку строковые данные хранятся в отдельном выделении, которое не перемещается, когда это делает сам String. Чтобы гарантировать, что это правильно, String должен существовать как минимум столько же, сколько структура данных, которая ссылается на его содержимое, и String не может быть изменен в течение этого времени.

Чтобы сделать эту работу более эргономичной, когда нам не нужен отдельный тип для каждого типа контейнера, мы можем создать признак с общим ассоциированным типом на протяжении всего срока службы («lifetime GAT»).

pub trait StringSliceContainer {
    type Container<'a>;
}

Теперь давайте реализуем для Vec<&str>.

impl StringSliceContainer for Vec<&str> {
    type Container<'a> = Vec<&'a str>;
}

Пока достаточно просто. Обратите внимание, что реализованный тип StringSliceContainer не обязательно должен совпадать с типом Container. Вместо этого мы могли бы создать свой собственный struct VecStr; и реализовать его, по-прежнему используя type Container<'a> = Vec<&'a str>;.

Есть несколько вещей, которые нам нужно иметь в виду, когда мы создаем свой собственный тип. Идея состоит в том, что для некоторой String реализации T::Container он будет владеть как T, так и StringSliceContainer. Есть две важные вещи, которые будут определять определение этого типа, и одна является следствием другой.

Во-первых, единственное допустимое время жизни, которое мы можем использовать, не вводя именованное время жизни, — это 'static. Это означает, что мы должны определить наш тип примерно так:

pub struct SelfOwnedStringSlices<T: StringSliceContainer> {
    _string: String,
    container: T::Container<'static>,
}

Однако это кажется неправильным... и это действительно так. T::Container<'static> это не так? Что ж, это лучшее, что мы можем здесь сделать. Важно то, что мы никогда не используем это поле как T::Container<'static>! Сначала мы всегда должны сокращать параметр времени жизни до значения, не превышающего время жизни нашей собственной строки.

Во-вторых, из-за этого мы не можем полагаться на сгенерированный компилятором склеивающий элемент, потому что он будет отбрасывать T::Container<'static>, что будет недопустимо. Поэтому мы должны настроить определение этой структуры, чтобы обернуть контейнер в ManuallyDrop . Это гарантирует, что сгенерированный компилятором склеивающий элемент фактически не отбросит это поле. Вместо этого мы сможем удалить его самостоятельно после того, как соответствующим образом скорректируем время жизни.

Итак, теперь у нас есть это:

pub struct SelfOwnedStringSlices<T: StringSliceContainer> {
    _string: String,
    container: ManuallyDrop<T::Container<'static>>,
}

Хорошо. Как нам сделать одну из этих вещей? Что ж, все, что нам нужно, это строка и способ создания T::Container<'static> из &'a str. За исключением того, что на самом деле мы не хотим, чтобы потребитель этого типа создавал T::Container<'static>, потому что тогда он не сможет ссылаться ни на что в строке! Поэтому им нужно дать нам возможность производить T::Container<'a> из &'a str. Это достаточно легко выразить замыканием.

impl<T: StringSliceContainer> SelfOwnedStringSlices<T> {
    pub fn new<F>(string: String, container_factory: F) -> Self
    where
        F: for<'a> FnOnce(&'a str) -> T::Container<'a>,
    {
        todo!()
    }
}

Тело этой функции должно вызвать замыкание, а затем создать новый Self, используя возвращенный контейнер и строку. Но мы получаем T::Container<'a>, а не T::Container<'static>! Что ж, к счастью, это один из случаев, когда трансмутация может нам помочь. Расположение типа не зависит от каких-либо параметров времени жизни, поэтому такая трансмутация безопасна. Однако, как упоминалось ранее, мы должны быть осторожны и никогда не использовать контейнер с этим сроком службы. Нам всегда нужно преобразовать время жизни обратно в то, которое не может превышать время жизни строки, которой мы владеем.

impl<T: StringSliceContainer> SelfOwnedStringSlices<T> {
    pub fn new<F>(string: String, container_factory: F) -> Self
    where
        F: for<'a> FnOnce(&'a str) -> T::Container<'a>,
    {
        let container = container_factory(&string);

        // SAFETY: We are only changing the lifetime parameter to be 'static,
        // and we will never actually use this container with the 'static
        // lifetime.
        let container =
            unsafe { std::mem::transmute::<T::Container<'_>, T::Container<'static>>(container) };

        Self {
            container: ManuallyDrop::new(container),
            _string: string,
        }
    }
}

Как нам теперь использовать контейнер? К счастью, по сути, это та же самая трансмутация в другом направлении (замена 'static на время жизни ссылки &self), только для ссылки на контейнер.

impl<T: StringSliceContainer> SelfOwnedStringSlices<T> {
    pub fn get<'a>(&'a self) -> &'a T::Container<'a> {
        // SAFETY: We are only changing the lifetime parameter, and we are
        // shortening it to the lifetime of the self reference, which ensures
        // that the caller cannot retain any (non-static) reference stored in
        // the container for longer than self exists.
        unsafe {
            std::mem::transmute::<&'a T::Container<'static>, &'a T::Container<'a>>(&self.container)
        }
    }
}

Не плохо.

Обратите внимание, что мы, к сожалению, не можем реализовать Deref, потому что при определении Deref::Target нам нужно будет использовать T::Container<'something>, но в этом контексте у нас нет ссылки, из которой мы могли бы получить время жизни.

Последняя часть головоломки — как мы справляемся с падением контейнера. Интересно, что нам нужно очистить время жизни в Drop::drop, чтобы у нас было именованное время жизни, в которое мы можем преобразовать параметр времени жизни контейнера. Как только у нас есть это именованное время жизни, трансмутация здесь происходит примерно так же, как в методе get выше, только с эксклюзивной ссылкой и сохранением слоя ManuallyDrop.

impl<T: StringSliceContainer> Drop for SelfOwnedStringSlices<T> {
    fn drop<'a>(&'a mut self) {
        // SAFETY: We change the lifetime of the container so it's safe to drop,
        // then we drop it.
        unsafe {
            let container = std::mem::transmute::<
                &'a mut ManuallyDrop<T::Container<'static>>,
                &'a mut ManuallyDrop<T::Container<'a>>,
            >(&mut self.container);

            ManuallyDrop::drop(container);
        }
    }
}

И мы закончили!

Использовать этот тип теперь очень просто:

let string = "this is a test".to_owned();

let vec = SelfOwnedStringSlices::<Vec<&str>>::new(
    string,
    |s| s.split_ascii_whitespace().collect()
);

println!("{:?}", vec.get());

(Детская площадка)

Обратите внимание, что здесь выполняется довольно много unsafe гимнастики. Насколько мне известно, здесь все сделано добротно. Однако решения, использующие String::leak и include_str!, не предполагают написания небезопасного кода, поэтому они тривиально доказуемы. Они также намного короче!

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

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