Войти
ФлеймФорумПрограммирование

Список модных прог в которых shared_ptr и weak_ptr и unordered_map хорошо зашли (2 стр)

Страницы: 1 2 3 417 Следующая »
#15
0:45, 18 авг. 2017

> А теперь?
Adler, теперь ясно что это какой-то полный бред.

> к unique_ptr у меня тоже есть вопросы, но суть в том, что его всегда можно заменить на std::vector.
С таким же успехом можно заменять яблоко трактором 8-)


#16
4:42, 18 авг. 2017

Мое имхо - умные указатели - это всего лишь синтаксический сахар. Где-то удобно. Где-то защищает от криворукости. Но вполне успешно живется и без этого...
Да и когда-нибудь мода пройдет - это как лет десять назад все бегали с Александреску и его шаблоно-магией

Все нужно использовать в меру и без фанатизма. Умные указатели полезны, но это не значит что нужны 100%

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

Adler
Могу написать пример где shared_ptr заходит:

class RendererDevice
{
      shared_ptr<Texture2D> CreateTexture(...);
      shared_ptr<Texture2D> GetTexture(...);
....

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

плюс, это банально удобно, когда работаешь с полиморфизмом классов:

class App
{
    unique_ptr<Renderer> m_renderer (new D3DRenderer);
}
И теперь не надо писать лишний код по удалению m_renderer.


ArchiDevil
> Ясно. Посоветую устроиться на работу и посмотреть, как пишут нормальные люди.
да-да. особенно там, где код написан еще в восьмидесятые (ну или в девяностые, если повезет), когда о таком ничего не слышали.
Работа, знаешь ли, разная бывает. не факт что там где работаешь - увидишь нормальное современное программирование (я вот у себя на работе не вижу - вообще бейсик)

#17
6:14, 18 авг. 2017

Adler
> трюк такой:
> было
> unique_ptr<i_base> //struct t_a:i_base{};struct t_b:i_base{};struct
> t_c:i_base{};struct t_d:i_base{};
>
> стало
> struct t_unique_ptr_i_base{
> vector<t_a> arr0;
> vector<t_b> arr1;
> vector<t_c> arr2;
> vector<t_d> arr3;
> ...
> size_t type;
> ...
> };
мои глаза, спасите-помогите

#18
7:39, 18 авг. 2017

slava_mib
Kartonagnick
ArchiDevil
The Player
Suslik
> Посоветую устроиться на работу
По моему он как раз уже работает
Вроде чувак хочет показать замену aos на soa.
Он еще и одну из индирекций указателя вынес вне цикла по вектору.


На этом форуме никто чтоль не оптимизирует кот?

#19
8:13, 18 авг. 2017

war_zes
> Сам использую по настроению.
ясно.

*Lain*
> Вроде чувак хочет показать замену aos на soa.
хз, что такое 'aos', но тема владения ресурсами
ортогональна теме 'service oriented architecture'

а сам чувак постулирует какой то бред.

*Lain*
> оптимизирует кот?
тема владения ресурсами ортогональная теме оптимизации котов.

#20
8:53, 18 авг. 2017

Kartonagnick
> хз, что такое 'aos', но тема владения ресурсами
> ортогональна теме 'service oriented architecture'
*Lain* вот про это писал.

#21
8:56, 18 авг. 2017

*Lain*
soa делается там, где simd-оптимизации, где требуется специфика лэйаута памяти, а не там, где автор не знает, для чего нужен unordered_map.

#22
9:03, 18 авг. 2017

Bowman
> *Lain* вот про это писал.
да я уже понял, что тс про попа, а Лайн про ярёму.

#23
9:07, 18 авг. 2017

Bowman

> *Lain* вот про это писал.
Ракыч не в курсе таких терминов. У него же, если массив влезает в кеш, то это по умолчанию cache friendly. А если не влезает, то нефиг тут вообще думать над алгоритмами.

#24
9:23, 18 авг. 2017

slava_mib
> теперь ясно
> Казалось бы - какая тут вообще связь?
> Ау? )))
факт наличия слабой связи подтверждаешь?

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

я показал как избавляться от shared_ptr в 90% случаев, а остальные 10% обозвал адовой оптимизацией и не использую.

Suslik
> soa делается там, где simd-оптимизации, где требуется специфика лэйаута памяти
да, т.к это увеличивает жизнеспособность продукта.

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

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

Нужен пример модной проги которой не надо взаимодействовать с внешними физическими устройствами/процессами вообще. Тоесть которая юзеает только проц и ОЗУ.
И история как в неё хорошо зашли и shared_ptr`ы и unordered_map`ы.

#25
9:38, 18 авг. 2017

Ghost2
> Ракыч не в курсе таких терминов
мне не понравилось, что vector без кастомного аллокатора. Как минимум нужно было на границу кеш линейки выровнять. А то и на границу страницы. но мне кажется это просто пример. по сути приблизительный. поэтому и симда не напихали

#26
9:47, 18 авг. 2017

Adler
> я показал как избавляться от shared_ptr
Эээ.

Изображение
#27
10:05, 18 авг. 2017

Kartonagnick
мне иногда кажется что ты слишком фанатичен. Чем-то ведь и правда походишь на эвангелистов Александреску, юнит-тестов и других подобных идеологов программирования
Ты не хочешь признавать простой факт - что любые инструменты нужно применять по назначению. Что иногда они могут быть избыточны для решаемой задачи.... В том числе и умные указатели
Ибо Бритва Оккама

И особенно неправилен подход, когда вы считаете что не используют что-то только те кто не осилил. Это ведь неверно.

Я использую умные указатели там где они необходимы.
А точнее там - где я не могу гарантировать 100% жизненный цикл объекта (как в примерах выше где менеджер создает ресурс и передает его куда-то дальше)
И с другой стороны если скорость написания важнее качества (например для прототипа) - я не буду использовать умные указатели

#28
11:09, 18 авг. 2017

Adler
> к unique_ptr у меня тоже есть вопросы, но суть в том, что его всегда можно
> заменить на std::vector.
джекичан.жпг

#29
11:11, 18 авг. 2017

Adler
> к unique_ptr у меня тоже есть вопросы, но суть в том, что его всегда можно
> заменить на std::vector
Писец...  При чем тут вектор и концепция владения объектом??  unique_ptr  как бы намекает, что владеет объектом, при чём только он один (потому убер лёгкий враппер, ибо нет счётчика ссылок) . И он же один ответственен за его удаление.  Shared_ptr - то же самое, но владельцев может быть много. И это прекрасная штука, ибо позволяет _передавать_ владение _стандартизированным_ образом без последствий, без забывания удалить и мудацких интерфейсов.

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

Texture* texture = createTexture(...); //Это мандец. Я скопирую куда-то поинтер и никогда не смогу быть умеренным, что он валидный, что его никто не удалил. А ещё мне нужна дурацкая функция, торчащая из интерфейса:
deleteTexture(Texture* texture); //Так как юзер _не знает_ как была создана текстура! И потмоу не имеет права делать delete, т.к. не факт даже, что структура через new создана и не обязательно в хипе.

С другой же стороны:

std::shared_ptr<Texture> texture = createTexture(...); //всё то же самое, синтаксис около идентичный, но! Удаление объекта:

texture = nullptr;  //или reset или присваивание другого поинтера. И всё. Объект удалится, при чём при создании shared_ptr можно указать deleter и удалять хоть из своего говнопула.  Скопированный не nullptr поинтер гарантирует, что объект жив и мне не нужно это перепроверять в тысяче мест а так же нет нужды в тупой функции deleteTexture и в её вызове в _неизвестный никому_ момент, т.к. не ясно сколько классов используют сейчас сырой поинтер.

Городить свои костыли так же тупо если компилер поддерживает стандартные поинтеры.

п.с. Для меня человек, который не вынужден работать со старым компилером и его не заставляют за деньги говнокодить сырые поинтеры, но он всё равно этим занимается - как минимум (назовём это культурно) "подозрителен".

Страницы: 1 2 3 417 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.