Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, T4r4sB, Вы писали:
TB>>Тебе на индексах, шаред поинтерах или ансейфе шоб 1в1 как в C++? CC>Мне чтоб быстро работал.
Двухсвязный список и шоб быстро работал?
Лучше вектор бери
Здравствуйте, Shmj, Вы писали:
S>Компилятор С++ это принимает и не пикнет — максимум варнинг выдаст, и то не всегда. А ведь это 100% ошибка без вариантов.
В этом и прелесть С++. Ты делаешь то, что хочешь. Однако, если ты не понимаешь что ты делаешь, то зачем вообще что-то писать?
S>Почему я начал почитывать Rust?
Лучше что-то писать на нём.
Здравствуйте, SkyDance, Вы писали:
TB>>Двухсвязный список и шоб быстро работал? TB>> TB>>Лучше вектор бери TB>>
SD>Кто-нибудь может объяснить, в чем именно юмор? И как вообще вектор относится к двусвязному списку?
У двусвязного списка все плохо с кешем.
Кстати а зачем он нужен? Я не моги припомнить таких случаев.
Что можно доказать, если к предыдущей реализации не возникло претензий? Вот если попробовать реализовать двусвязный список на С++ не на голых указателях, всё равно ведь придём к подобной реализации на shared_ и weak_ptr. Ну можно сократить на optional. И вовсе не из-за того что в Rust запрещены нулевые указатели, а из-за того что optional в С++ настолько калечный, что проще без него.
Здравствуйте, 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>Ну, это уже передёргивание. Никто тут не говорил, что не надо пользоваться кучей. Вопрос был, зачем в данном конкретном случае писать такие ужасы. С просьбой заменить искусственный пример хоть сколько-нибудь реальным. В ответ прозвучало, мол, у нас в стек ничего не влезет.
Здравствуйте, SkyDance, Вы писали:
SD>Кто-нибудь может объяснить, в чем именно юмор? И как вообще вектор относится к двусвязному списку?
Да у него сова не налазит и потому он Камалу включает — начинает ржать.
Здравствуйте, Shmj, Вы писали:
S>Ну вот вам с передачей в функцию по ссылке. Что не так:
S> Class2Wrapper(std::unique_ptr<Class1> &inner) S> { S> _inner = std::move(inner); S> }
Это очевиднейший говнокод.
Переделывай на &&
А как переделаешь — в другом месте вылезет очевидность
Здравствуйте, 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 (из новых стандартов).
Здравствуйте, 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
