Атака на пакет arrayref Rust

Хороший вопрос!

Ха, вы меня сподвигли, я тут почитал про раст, этот Rc<RefCell<…>> оказывается вовсе не бесплатный в рантайме. Там и дополнительные проверки в рантайме и дополнительная память…

В нашем случае двусвязного списка, например, выходит минимум +24 байта на каждый узел! И borrow_mut() и next.clone() тоже не бесплатны, а выполняют проверки в рантайме.

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

По-моему первый вариант куда понятней и проще.

#include <memory>
#include <cstddef>

template <typename T>
class LinkedList
{
    struct Node;

    using Link = std::shared_ptr<Node>;
    using Prev = std::weak_ptr<Node>;

    struct Node
    {
        T value;
        Prev prev;
        Link next;
    };

public:
    LinkedList() = default;

    void push_front(const T& value)
    {
        auto node = std::make_shared<Node>(
            Node{
                .value = value,
                .prev = {},
                .next = head_
            }
        );

        if (head_) {
            head_->prev = node;
        } else {
            tail_ = node;
        }

        head_ = node;
        ++len_;
    }

    void push_back(const T& value)
    {
        auto node = std::make_shared<Node>(
            Node{
                .value = value,
                .prev = tail_,
                .next = {}
            }
        );

        if (tail_) {
            tail_->next = node;
        } else {
            head_ = node;
        }

        tail_ = node;
        ++len_;
    }

    void remove(const std::shared_ptr<Node>& node)
    {
        auto prev = node->prev.lock();
        auto next = node->next;

        if (prev) {
            prev->next = next;
        } else {
            head_ = next;
        }

        if (next) {
            next->prev = prev;
        } else {
            tail_ = prev;
        }

        node->prev.reset();
        node->next.reset();

        --len_;
    }

    std::size_t size() const
    {
        return len_;
    }

private:
    Link head_;
    Link tail_;
    std::size_t len_ = 0;
};

не бесплатный в рантайме

Удивительно, да? Оказывается, двусвязный список в общем виде не может обойтись без рантаймовых проверок.

без рантайм проверок

std::make_shared, std::weak_ptr

/0

да, согласен, в данном случае умные указатели не нужны и всё усложняют

ты уточни, что именно бесполезно? идея владения через unique_ptr?

Тебе же скинули ссылку на стд коллекции раста, там список реализовван на указателях, без рантайм оверхеда.

Хороший аргумент, тут двусвязный оправдан по асимптотике, много перестановок. Но на векторах/аренах + хранении индексов вместо указателей будет быстрее и намного более кеш-френдли (логически это тоже будет тот же список, но физически мы не храним адреса и лишены pointer chasing недостатков).

Что еще кроме lru, который уже 100 лет назад реализован и лежит в стандартных либах?

Не хочешь рантайм проверок, делаешь на NonNull<Node> + unsafe. ПО представлению будет также как в твоих любимых крестах, но с у тебя не получится забыть сделать nullptr-проверку перед разыменовыванием, чего вы регулярно практикуете в ваших сишках.

Конечно это должен быть список поверх массива, я же говорю, не в такой реализации. В прочем, не думаю что здесь Си Сипупу и Растокод будут сильно отличимы.

В каком-то виде непременно попадёт. Сейчас уже делают безопасные профили для с++29. Правда 100% гарантий как в расте в них пока ещё не будет, но однажды сделают и это, ведь запрос есть, давление на комитет думаю очень сильное, да и сам комитет проголосовал что будет в этом направлении двигаться.

Вот, например, пишут

In many polls the committee has indicated a strong desire to make C++ a safer language, and that the design intent of profiles are a great way to do it...

... C++ has been pushed since at least 2021 to become a more memory safe language, typically being lopped in with C.

То есть вопрос не стоит, будут ли делать с++ более безопасным или нет, этот вопрос уже решён. И уже решено что первым этапом будут безопасные профили.

Я лично предпочёл бы какое-то подмножество языка, то есть чтобы хотя бы новый код можно было писать с полной гарантией как в расте. Почему нет? И старый подход останется и будет новый, для особых задач, если понадобится.

Конечно. А ещё я не смог нагуглить addChild метод. Ты где его взял?

Господи, да что они там сделают? Лучше бы закапывали. Впрочем, то что они делают — закапывание и есть.

Ну дык, конечно, если с unsafe, без 100% гарантий, в том же виде как на с++, то и вопросов никаких нет :)

Претензия была - значительно усложнение кода в стандартном безопасном режиме. Оно есть и видно невооружённым взглядом. Плюс дополнительная память, плюс дополнительные расходы процессора. Это не происки противников Раста, как выяснилось, это факт. То есть 100% гарантия далеко не бесплатна. Заявления о той же производительности, но с гарантиями - неправда.

А следовательно вопрос, а надо ли оно ширнармассам, а не только в особых отдельных случаях тоже остаётся.

Господи, да что они там сделают? Лучше бы закапывали. Впрочем, то что они делают — закапывание и есть.

Здесь я с тобой, к сожалению, отчасти согласен. Моя уверенность в способности комитета выдавать годные решения, отвечающие реальным потребностям реальных людей, у меня тоже вызывает сомнения.

Но прям такой уверенности, что они уже ничего не смогут сделать в этой области и с++ обречён, у меня нет. Есть пример раста, есть опыт его применения, то есть по-идее комитету будет легче, они смогут учесть весь его опыт. Им не надо будет выдумывать всё это заново.

Так это же пример, как бы мог выглядеить API Qt, написанный на современном с++. addChild() внутри может делать тоже самое, то есть make_unique и возвращать обратно ссылку. Вся разница лишь в том что make_unique будет спрятано в addChild().

Кроме двусвязных списков есть ещё графы со множеством ссылок; деревья у которых узел ссылается на родителя; те же ГУИ, где не только родители владеют детьми, но и дети хранят указатель на родителя, как в Qt, да плюс ещё куча связей между объектами может быть (те же сигналы). И там везде будут похожие проблемы, как в двусвязном списке, которые в с++ будет выражаться простым указателем. А вот как в Расте не знаю, но уже вижу что там нужно будет голову ломать очень серьёзно. Ну или сразу включать unsafe.

Претензия была - значительно усложнение кода в стандартном безопасном режиме.

Усложнения нет, это skill issue. Наоборот, в языке много сахарку, помогающего упростить код.

То есть 100% гарантия далеко не бесплатна.

Никто из авторов раста такое не заявлял.

Заявления о той же производительности, но с гарантиями - неправда.

Обоснуй. Большинство проверок раста в компайл тайме. В рантайме тоже есть проверки, но они есть в аналогичных кейсах и на плюсах, следовательно с++ не нужен?

А следовательно вопрос, а надо ли оно ширнармассам, а не только в особых отдельных случаях тоже остаётся.

Ты вдруг решил что можешь за массы говорить? Люди сами выбирают раст, потому что видят в нем очевидные преимущества, почему ты вдруг решил что должно быть важно твое мнение? Лично ты можешь отрицать реальность, но корпы переводят разработку на раст, с/с++ потихоньку вытесняют. Будешь следовать своей си-религии - останешься за бортом, будешь чинить только легаси.

Хочешь выйти за некоторые рамки гарантий компилятора, используешь unsafe с сырыми указателями. Ты почему-то решил, что гуй везде должен быть устроен как Qt. Подходов давно куча, и Qt подобный тоже реализуем. Ты просто смешиваешь граф связей с графом владения. То, что два объекта должны знать друг о друге, не значит, что они обязаны владеть друг другом или хранить прямые ссылки друг на друга. Связи можно хранить через ид, хендлы, события, сообщения и другие прослойки, не превращая структуру программы в паутину взаимного владения. Люди не особо беспокоятся о тех проблемах, которые ты описываешь, потому что архитектурно давно научились их обходить. Вообще ты будто на 10 лет отстал, посмотри, сколько гуи-библиотек уже есть в расте.

Усложнения нет, это skill issue. Наоборот, в языке много сахарку, помогающего упростить код.

Вот это отнюдь не тривиальный ход

type Link<T> = Option<Rc<RefCell<Node<T>>>>;
type Prev<T> = Option<Weak<RefCell<Node<T>>>>;

Если бы я сел писать, имея в багажнике только знания о том как устроен классический список, то мне придётся как-то догадаться, что два абсолютно равнозначных указателя в классической реализации должны быть заменены на два разных типа указателя здесь. Это вовсе не следует из логики класса (и последующий и предыдущий член абсолютно равнозначны), а обусловлено особенностями этих указателей. По сути это трюк, который сработал, причём трюк до которого надо как-то догадаться, либо про него где-то прочитать. И это трюк, которые не облегчает понимание кода, почему-то вдруг указатель на предыдущий элемент отличается от указателя на такой же последующий.

В то же время тривиальная реализация классического списка на с/с++ не требует никаких догадок и трюков.

Так что нет, усложняет и усложняет значительно.

они есть в аналогичных кейсах и на плюсах

неправда

давно научились их обходить.

Если для написания простого кода нужно придумывать какие-то способы обхода и борьбы с компилятором, то значит где-то что-то не так. Простые задачи должны решаться просто.

Лично ты можешь отрицать реальность, но корпы переводят разработку на раст, с/с++ потихоньку вытесняют. Будешь следовать своей си-религии - останешься за бортом, будешь чинить только легаси.

Вот это, конечно, будет очень печально, если с/c++ похоронят. Поэтому я надеюсь на комитет, что они что-то слепят, чтобы корпы признали с/с++ безопасным. Правда от нас тут мало чего зависит, если корпы чего-то решили, то скорее всего так и будет. Ну блин, тогда придётся учить ваш раст.

Впрочем, по-моему джава должна была тоже похоронить с++ и корпы на неё массово переходили…

Кстати, тоже под лозунгом безопасного языка :)

но корпы переводят разработку на раст

Да пусть куда угодно переводят, их дело. Мне то что с того?

Поэтому я надеюсь на комитет,

Это ты зря.

если корпы чего-то решили, то скорее всего так и будет. Ну блин, тогда придётся учить ваш раст.

Это надо считать признанием в корпофажестве?

Будем надеяться, что с растом будет как с джавой и го, а с++ просто обогатится безопасным режимом или какими-то другими безопасными технологиями.

Иначе… а куда деваться… Деньги же надо будет зарабатывать…

Поэтому я надеюсь на комитет, что они что-то слепят, чтобы корпы признали с/с++ безопасным.

Это будет хорошо.

Хм, ты точно программируешь на с++?)

• std::unique_ptr<T> == Box<T>. Оба имеют минимальный рантайм оверхед.
• std::shared_ptr<T> ~= Rc<T> или Arc<T>. Рефкаунты, очевидно без рантайма никак, причем раст разделяет многопоточную и однопоточную версии для оптимальной скорости.
• std::weak_ptr<T> == Weak<T> - рефкаунт слабых ссылок, очевидно с рантаймом. Также всякие Mutex, RwLock итд все с рантайм проверками, вряд ли ты будешь с этим спорить.

Других растовых аналогов у с++ типа RefCell<T> или Cell<T> я не знаю, это вообще растовая фишка.

Что в итоге? В компайл тайм есть только ссылки &T и &mut T (у крестов просто &T), и указатели *mut T, *const T (с++ T*, const T*). Все что безоверхедное в с++ есть и в расте.

Так в чем неправда?

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

Говоришь так, будто я тебя уговариваю перейти на раст. Мне, в общем-то, плевать.

Вот это отнюдь не тривиальный ход

Покажи аналог на с++, если это возможно вообще.

Если бы я сел писать, имея в багажнике только знания о том как устроен классический список…

И это проблема языка? Раст не обязан подстраиваться под человека, который знает только одну модель. Аналогичный код с такими же компайл-тайм гарантиями ты на с++ не напишешь. Хочешь как в плюсах, бери *const T / *mut T и получай примерно ту же простоту, только валидность указателей и время жизни теперь проверяешь сам (unsafe). В этом и вся разница.

Так что нет, усложняет и усложняет значительно.

Нет же, это вопрос твоего выбора. Можешь сложно но с гарантиями и платишь оверхедом, можешь просто и быстро, но будь максимально внимателен.

Не уверен, поезд уже скорее всего ушел, комитет его проспал. Safe редизайн с++ это полный слом обратной совместимости, фактически это будет другой язык, с синтаксисом похожим на с++. Возможно это кстати верное решение, выпустить с++ 2.0, но кому он уже нужен, когда корпы (а значит 90% написанного кода) уже переехали.

Полностью safe C++ невозможен в принципе (да и не нужно). Но большинство UB заменят на CE..

А где это «как надо»?

Не знаю, по большинство попсовых проектов кодят по принципу «подешевле и побыстрее».

Не нужны там ни std::unique_ptr, ни std::shared_ptr. Правильная классическая с++ реализация - первая. Она же самая эффективная, быстрая, читабельная, понятная, простая, потребляющая меньше памяти и ресурсов процессора. Это и есть эталонный с++ аналог двусвязного списка на с++. Единственное в чём она уступает версии на расте, она не даёт 100% безопасности при работе с памятью.

Если же нужна безопасность как в расте, то да, нужно извращаться, как в расте. Нужно придумывать «обходные пути», как ты говоришь, может в массиве размещать или ещё как-то, мне это не интересно сейчас, практического значения для большинства проектов это не имеет. В данном конкретном случае, в случае двусвязного списка, умные указатели в с++ не нужны, если ты не программируешь какой-то уникальный мегадорогой суперкритический проект где тебе нужны действительно 100% гарантии.

Что касается доп. расходов, то в с++, даже с умными указателями не будет borrow(), borrow_mut() потому что их попросту нет. :) Но это неважно, потому что в общем случае на с++ так писать не будут.

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

Ну или выбрать подходящий язык для задачи, который позволит решить задачу быстрее, проще и эффективней.

Покажи аналог на с++, если это возможно вообще.

я показал тебе аналог, которые быстрее, эффективнее и проще, но не даёт 100% гарантий от определённых ошибок.

Аналогичный код с такими же компайл-тайм гарантиями ты на с++ не напишешь.

Там ещё и рантайм проверки. Извратиться и написать что-то подобное на с++ конечно можно, но это будет непростая задача, куда более сложный код и далеко не факт что получится эффективней раста. Надеюсь, что комитет эту задачу решит в будущем. А пока да - очень трудно.

Нет же, это вопрос твоего выбора. Можешь сложно но с гарантиями и платишь оверхедом, можешь просто и быстро, но будь максимально внимателен.

В реальном мире выбора большого не будет. Ты же будешь использовать какие-то библиотеки, фреймвёрки, легаси и т.п., которые будут тебя сильно ограничивать. Но я согласен, сейчас именно в этом безусловно и заключается преимущество раста над с/с++.

Не уверен, поезд уже скорее всего ушел, комитет его проспал. Safe редизайн с++ это полный слом обратной совместимости, фактически это будет другой язык, с синтаксисом похожим на с++. Возможно это кстати верное решение, выпустить с++ 2.0, но кому он уже нужен, когда корпы (а значит 90% написанного кода) уже переехали.

С++ проекты никуда не денутся ещё десятки лет, даже если прямо сейчас всех обязать это сделать законодательно, так что времени у комитета достаточно, да и мне до пенсии точно хватит. ;) Вот молодёжи стоит задуматься, как минимум держатьр руку на пульсе. :)

А корпы уже переходили на безопасную яву (которая якобы даже быстрее с++ в некоторых случаях), потом ещё безопасный го был, может ещё что-то пропустил. Это не показатель. Где-то перейдут, а где-то нет. В итоге они с питоном хоть и отъели у с++ кусок, но никуда он не делся.

Но ты прав в том, что есть ненулевая вероятность того, что популярность раст действительно взлетит, а популярность с++ останется в прошлом, как это случилось с разными другими популярными в прошлом языками.

И что значит «корпы уже переехали»? На сколько я знаю, это сильное преувеличение.

Ну или выбрать подходящий язык для задачи, который позволит решить задачу быстрее, проще и эффективней.

Конечно! Это важно. Но ты выбросил критерий надежности из своего пула, для некоторых это неприемлемо.

С++ проекты никуда не денутся ещё десятки лет, даже если прямо сейчас всех обязать это сделать законодательно, так что времени у комитета достаточно, да и мне до пенсии точно хватит. ;) Вот молодёжи стоит задуматься, как минимум держатьр руку на пульсе.

Ох недооцениваешь ты ситуацию! Сейчас все быстро на клаудах перепишут, не успеешь моргнуть :)

А корпы уже переходили на безопасную яву…

А корпы и перешли на яву. Ты думаешь на чем они пилят свои бизнесы, не на плюсах же)

И что значит «корпы уже переехали»? На сколько я знаю, это сильное преувеличение.

Да, это чтобы вас сишников подергать за усы. Но тенденция и тренды уже вырисовываются. Но я не понимаю переживаний этих, язык это же просто инструмент, нужно будет перейдешь и на раст и на джаву. Какая разница на чем писать, лишь бы платили. Но если бы у меня был выбор раст/с++, то тут выбор для меня очевиден, я вообще не представляю кто в здравом уме добровольно хочет ежедневно видеть плюсы.

Я просто дополнил тебя. Конечно, для кого-то надёжность перевесит всё остальное. Если раньше эти люди должны были мириться с существенным проседанием производительности или повышенным потреблением ресурсов, как с явой, питоном и проч., то теперь у них появился ещё и раст. Это прекрасно. Также спасибо расту, за то что комитет с++ тоже озаботился этим вопросом. Без раста это никогда не произошло бы (и это большой жирный минус комитету).

Ох недооцениваешь ты ситуацию! Сейчас все быстро на клаудах перепишут, не успеешь моргнуть :)

Тут куда более простые вещи внедряешь годами, а ты - перейти на раст. Ну разве что если нейронками это всё ворочать. Но если переходить на нейронки, то тогда особо и неважно, что там за язык, пусть они там сами разбираются… :)

Но я не понимаю переживаний этих, язык это же просто инструмент, нужно будет перейдешь и на раст и на джаву. Какая разница на чем писать, лишь бы платили. Но если бы у меня был выбор раст/с++, то тут выбор для меня очевиден, я вообще не представляю кто в здравом уме добровольно хочет ежедневно видеть плюсы.

Я хоть завтра перейду, но это абсолютно неправильный подход, когда выкидывается существующая огромная кодовая база и опыт людей. Даже с++ 2.0, пусть даже отчасти несовместимый, будет гораздо лучшим решением.

Если в репе уже лежат миллионы строк на с++, написанные за 30+ лет, то для небольшой фирмы какой выход? Закрыться на пару лет чтобы переписать всё на расте? А кто платить за это будет?

С++ проекты никуда не денутся

Тут уже проектов на Rust вагон и тележка:
https://github.com/rust-unofficial/awesome-rust
https://terminaltrove.com/language/rust/

Обойдут по популярности - и всего делов. Даже не надо куда-то чего-то девать.

Раст форсят в ж0ской форме, «сами вибирают» — это только часть. Результат, можно предположить, будет такой же, как с форсингом ЦеПеПе: крестьяни наелись листьев и отравылысь.

Что плохого-то в похоронах цепепе?

Что плохого-то в похоронах цепепе?

Если в репе уже лежат миллионы строк на с++, написанные за 30+ лет, то для небольшой фирмы какой выход? Закрыться на пару лет чтобы переписать всё на расте? А кто платить за это будет?

А с большинством свободных проектов всё ещё хуже. Там в принципе финансировать некому, за исключением десятка популярных проектов. Поэтому нужен безопасный с/с++

Обойдут по популярности - и всего делов.

Если обойдут, то да. А так нет ;)

На самом деле весёлого ничего нет. Если свежих сишников не будет, то в результате свободные сишные и с++ проекты останутся висеть в воздухе без сопровождения (и это, кстати, ещё больше ухудшит ситуацию с безопасностью - забавно да?). С сями и так отчасти уже это произошло, сишников стало слишком мало. с++ пока держится.

Так что правильное решение - максимально совместимый безопасный си и с++.

Так Rust в современном мире как раз и заменяет C/C++. Всё нужное перепишут на Rust'е.