Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, T4r4sB, Вы писали:

TB>>Тебе на индексах, шаред поинтерах или ансейфе шоб 1в1 как в C++?
CC>Мне чтоб быстро работал.

Двухсвязный список и шоб быстро работал?

Лучше вектор бери

Здравствуйте, Shmj, Вы писали:

S>Компилятор С++ это принимает и не пикнет — максимум варнинг выдаст, и то не всегда. А ведь это 100% ошибка без вариантов.
В этом и прелесть С++. Ты делаешь то, что хочешь. Однако, если ты не понимаешь что ты делаешь, то зачем вообще что-то писать?

S>Почему я начал почитывать Rust?
Лучше что-то писать на нём.

TB>Двухсвязный список и шоб быстро работал?
TB>
TB>Лучше вектор бери
TB>

Кто-нибудь может объяснить, в чем именно юмор? И как вообще вектор относится к двусвязному списку?

Здравствуйте, SkyDance, Вы писали:

TB>>Двухсвязный список и шоб быстро работал?
TB>>
TB>>Лучше вектор бери
TB>>

SD>Кто-нибудь может объяснить, в чем именно юмор? И как вообще вектор относится к двусвязному списку?

У двусвязного списка все плохо с кешем.
Кстати а зачем он нужен? Я не моги припомнить таких случаев.

Здравствуйте, CreatorCray, Вы писали:

CC>А теперь покажи doubly linked list

а смысл есть? Ну вот.

struct Node<T> {
    data: T,
    prev: Option<Weak<Node<T>>>,
    next: Option<Rc<Node<T>>>,
}

Что можно доказать, если к предыдущей реализации не возникло претензий? Вот если попробовать реализовать двусвязный список на С++ не на голых указателях, всё равно ведь придём к подобной реализации на shared_ и weak_ptr. Ну можно сократить на optional. И вовсе не из-за того что в Rust запрещены нулевые указатели, а из-за того что optional в С++ настолько калечный, что проще без него.

template<typename T>
struct Node {
    T data;
    std::shared_ptr<Node<T>> next;
    std::weak_ptr<Node<T>> prev;
};

Не особо то и проще. Но зато с UB

Здравствуйте, Shmj, Вы писали:

A>>А теперь посмотри на заголовок темы: "Превосходство Rust над C++". Ты же не уточняешь: "Превосходство Rust над C++ на гипотетическом устройстве, у которого проблемы со стеком" (потому, что в этом случае яркого флейма не выйдет).

S>Каков размер стека по умолчанию примерно? ˜ 1 МБ или больше?

S>Т.е. вы не сможете использовать больше 1 Мб памяти по умолчанию в стеке — это даже фотку нельзя обработать.

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

Вот я смотрю на свой код, который делает снимки экрана и ресайзит их, и там нет ничего из того, что есть в твоём примере. Он работает с кучей, но неявно. И контейнер изображения (кстати, библиотечный) передаётся в аналог fun1() по ссылке. Ссылке, простой как три рубля.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Shmj, Вы писали:

S>>Что не так?
CC>Для начала, у тебя фнукция принимает unique_ptr по значению. Что ты этим хотел сказать?

Ну вот вам с передачей в функцию по ссылке. Что не так:

#include <iostream>
#include <memory>

struct Class1 { const int i1 = 42; };

struct Class2Wrapper
{
    Class2Wrapper(std::unique_ptr<Class1> &inner)
    {
        _inner = std::move(inner);
    }

    void print() { std::cout << _inner->i1 << std::endl; }
    
private:
    std::unique_ptr<Class1> _inner;
};

void fun1(std::unique_ptr<Class1>& smart_ptr)
{
    // Удобно обернули, чтобы удобно использовать
    Class2Wrapper wrapper(smart_ptr);

    wrapper.print();
}

int main() {
    auto smart_ptr = std::make_unique<Class1>();
    fun1(smart_ptr); // передали по сслыке, все ОК

    std::cout << smart_ptr->i1 << std::endl; // тролололошеньки!!!

    return 0;
}

Здравствуйте, Alekzander, Вы писали:

A>Ну, это уже передёргивание. Никто тут не говорил, что не надо пользоваться кучей. Вопрос был, зачем в данном конкретном случае писать такие ужасы. С просьбой заменить искусственный пример хоть сколько-нибудь реальным. В ответ прозвучало, мол, у нас в стек ничего не влезет.

Вот тут: https://rsdn.org/forum/flame.comp/8599316.1

Автор: Shmj
Дата: 13.09.23

Здравствуйте, Shmj, Вы писали:

S>А по сути есть что сказать?

Это и есть по сути.

Здравствуйте, SkyDance, Вы писали:

SD>Кто-нибудь может объяснить, в чем именно юмор? И как вообще вектор относится к двусвязному списку?
Да у него сова не налазит и потому он Камалу включает — начинает ржать.

Здравствуйте, Shmj, Вы писали:

S>Ну вот вам с передачей в функцию по ссылке. Что не так:

S> Class2Wrapper(std::unique_ptr<Class1> &inner)
S> {
S> _inner = std::move(inner);
S> }
Это очевиднейший говнокод.
Переделывай на &&
А как переделаешь — в другом месте вылезет очевидность

Здравствуйте, CreatorCray, Вы писали:

CC>Это очевиднейший говнокод.
CC>Переделывай на &&
CC>А как переделаешь — в другом месте вылезет очевидность

Но компилятор даже warning не выдал

А ведь в более развитых системных языках — такое отлавливается на уровне компиляции.

Здравствуйте, Shmj, Вы писали:

S>Но компилятор даже warning не выдал
А должен?
Компилятор не обязан угадывать что именно хотел сделать пейсатель. Если бы мог — писал бы код сам, без привлечения кожаных мешков.

S>А ведь в более развитых системных языках — такое отлавливается на уровне компиляции.
Отсутсвие мыслительного процесса в межушном ганглии не отлавливается ничем.

Здравствуйте, sergii.p, Вы писали:

SP>Что можно доказать, если к предыдущей реализации не возникло претензий? Вот если попробовать реализовать двусвязный список на С++ не на голых указателях, всё равно ведь придём к подобной реализации на shared_ и weak_ptr.

А зачем? Какой смысл в C++ внутри Node использовать умные указатели, да еще и с подсчетом ссылок?
По идее, Node должны быть под капотом в каком-то классе-контейнере. И деструктор этого контейнера простым циклом удаляет все содержимое.
Если удаление не делать простым циклом, а полагаться на вызовы деструкторов, то при больших размерах списков можно переполнить стек рекурсией вызова деструкторов. Ну а раз ручной цикл в деструкторе контейнера нужен, то в чем смысл умных указателей в Node?

SP>Ну можно сократить на optional. И вовсе не из-за того что в Rust запрещены нулевые указатели, а из-за того что optional в С++ настолько калечный, что проще без него.

В C++ std::optional<some_type*> сам по себе имеет мало смысла. Разве что для тех редких ситуаций, когда nullptr входит в число легальных значений и нам нужно понимать есть ли вообще какое-то значение (включая nullptr) или нет. Но в таких случаях std::optional вовсе не калечный, т.к. nullptr не может использоваться как признак отсутствия значения, все равно нужен еще один bool.

Если же nullptr в число легальных значений не входит, то простой some_type* работает не хуже std::optional<some_type*>. И optional нужен разве что в случае, когда код написан с расчетом именно на optional, т.е. с использованием has_value, value, then (из новых стандартов).

Здравствуйте, so5team, Вы писали:

Чукча не практик. Чукча теоретег

Здравствуйте, Shmj, Вы писали:

Ок, пиши на Rust.

Здравствуйте, Shmj, Вы писали:

S>Но компилятор даже warning не выдал
S>А ведь в более развитых системных языках — такое отлавливается на уровне компиляции.

Ну, дело за малым — развитым системным язком с детектором ошибок в ДНК "программиста" и вызовом утилизационной бригады.

Здравствуйте, so5team, Вы писали:

S>А зачем? Какой смысл в C++ внутри Node использовать умные указатели, да еще и с подсчетом ссылок?

ну банально чтобы не получить утечку памяти. Ручное удаление может не так уж плохо в С, а в С++ летают исключения — RAII скорей не роскошь, а необходимость.

S>В C++ std::optional<some_type*> сам по себе имеет мало смысла. Разве что для тех редких ситуаций, когда nullptr входит в число легальных значений и нам нужно понимать есть ли вообще какое-то значение (включая nullptr) или нет. Но в таких случаях std::optional вовсе не калечный, т.к. nullptr не может использоваться как признак отсутствия значения, все равно нужен еще один bool.

S>Если же nullptr в число легальных значений не входит, то простой some_type* работает не хуже std::optional<some_type*>. И optional нужен разве что в случае, когда код написан с расчетом именно на optional, т.е. с использованием has_value, value, then (из новых стандартов).

первый случай тяжело представить в реальном мире, а второй вариант прекрасно реализован во многих языках. Что мешало сделать перегрузку и в С++?
А калечный optional в частности потому что "some_type* работает не хуже". То есть применение бессмысленно. Я уж не говорю про другие проблемы, как то что не поддерживает ссылки, до С++23 нет монадических интерфейсов, operator->() может приводить к UB. В общем коммитет постарался даже лучше чем Бог над черепахой.

Здравствуйте, Нomunculus, Вы писали:

Н>Здравствуйте, Shmj, Вы писали:
Н>Ок, пиши на Rust.

Ну так может добавите туда ООП полноценное? Слова то уже зарезервировали, но пока не осилили добавить — ссылаются что это никому не нужно. А вот нужно, ребятки, нужно. ООП — это суровая правда жизни.

Здравствуйте, sergii.p, Вы писали:

S>>А зачем? Какой смысл в C++ внутри Node использовать умные указатели, да еще и с подсчетом ссылок?

SP>ну банально чтобы не получить утечку памяти. Ручное удаление может не так уж плохо в С, а в С++ летают исключения — RAII скорей не роскошь, а необходимость.

Исключения могут летать в методах класса-контейнера при добавлении нового элемента. Там нужно обеспечивать exception safety в любом случае. И там это можно делать за счет, например, временного помещения нового элемента, еще не провязанного в список, в std::unique_ptr с последующим вызовом release при успешном окончании. Так что смысла хранить внутри Node умные указатели нет (ну разве что std::unique_ptr, если контейнер пишется наспех и нет ресурсов делать хорошую реализацию).

SP>первый случай тяжело представить в реальном мире,

Это да.

SP>Что мешало сделать перегрузку и в С++?

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

SP>А калечный optional в частности потому что "some_type* работает не хуже". То есть применение бессмысленно.

Заключение указателя в optional в C++ общем случае бессмысленно, т.к. этот указатель и есть optional.

SP>как то что не поддерживает ссылки

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

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

SP>до С++23 нет монадических интерфейсов

Обычная эволюция. Корни же растут из boost::optional лохматых нулевых годов, тогда в C++ монадическими интерфейсами даже Александреску не занимался

SP>operator->() может приводить к UB

А вот это как раз понятно. Дали возможность максимально дешевого обращения к содержимому переложив ответственность на программиста. Так же, как в std::vector есть operator[[] и at