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

В предыдущем примере pFufel оставался живым, если не было исключения, а у тебя удаляется.
Совсем другой код у тебя, судя по внешним эффектам.

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

S>>В контейнерах и массивах указатели.
I>Еще раз, у тебя есть:
I>

	Скрытый текст
	I> I>class Tmp I>{ I> std::vector<Pointer*> m_pointers; I>}; I>

I>Вот этот класс Tmp который содержит масив указателей или сам голый указатель, он может копироваться, может сам класс Tmp так же оказаться в векторе, может передаваться по значению и т.д.?
Зачем мне его копировать?

Здравствуйте, Кондраций, Вы писали:

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

К>В предыдущем примере pFufel оставался живым, если не было исключения, а у тебя удаляется.
К>Совсем другой код у тебя, судя по внешним эффектам.

Ты про этот?

Fufel* pFufel = new SuperPuperFufel;
try
{
  do_something(pFufel);
}
catch(exception1& e1)
{
    delete pFufel;
}
catch(exception2& e2)
{
    delete pFufel;
}
catch(exception3& e3)
{
    delete pFufel;
}
catch(...)
{
    delete pFufel;
   // не знаю, что делать с исключением
   throw; // пробросить его наверх
}

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

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

_>>Ну для начала это будет намного медленнее. Потому что подобная косвенная адресация убивает кэш процессора.
lpd>В данном случае действительно, список удобнее (я зря упомянул вектор, хотя во многих других случаях он может понадобиться).

Для любого неинтрузивного контейнера код с container<element*> будет медленнее чем container<element> просто за счёт лишнего уровня косвенности. В случае же контейнеров с непрерывной областью хранения элементов (типа vector'а), этот эффект ещё многократно усиливается за счёт работы кэша процессора.

lpd>Но медленнее? Для класса сетевого соединения, серьезно? Оптимизировать имеет смысл только самые критичные участки программы — излишняя оптимизация только усложняет код, без заметной пользы. При выборе типа структур данных гораздо важнее удобство использования, там где они нужны, чем скорость — в большинстве случаев.

Естественно удобство важнее в большинстве случаев. Только вот я предлагаю сравнить объём кода с указателями и без них — думаю что без будет существенно меньше писанины...

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

lpd>>>ОК, в данном случае можно хранить в list. Вообще, я предпочел бы сразу выделить объект в динамической памяти, проинициализировать и обработать его, и только потом добавить в list.
_>>Почему обязательно в динамической памяти, а не на стеке?
lpd>Раз объект будет в результате в динамической памяти, то логично сразу там его и выделить, и не мучаться с конструкторами перемещения, которые еще может понадобиться писать вручную только для этого.

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

_>>Сама по себе динамическая память — это конечно же не зло, а наоборот основа всего программирования. Злом же являются:
_>>- излишняя косвенность при обращение к памяти
_>>- неавтоматическое освобождение памяти.
lpd>С недостатками неавтоматического освобождения спорить сложно. Однако
lpd>- вместо неявного освобождения unique_ptr<>, лично я предпочту вручную явно вызвать delete. Хотя да, это вопрос вкуса, спорить наверное бесполезно.

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

lpd>- если время жизни объекта неизвестно, то в этом случае shared_ptr может помочь. Но на мой взгляд опциональный сборщик мусора был бы удобнее, чтобы не заботиться о круговых ссылках.

Если очень надо, то можно его взять например здесь: https://www.hboehm.info/gc/. Но лично мне даже shared_ptr очень редко нужен. Особенно с приходом семантики перемещения, которая совместно с моделью акторов решает очень многие проблемы владения объектами.

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

_>Нет, динамическая память имеет смысл или при больших объёмах (каждого элемента) или при динамическом полиморфизме. В остальных случаях имеет смысл работать со стеком и типами-значениями. Это и удобнее и эффективнее по производительности. Если есть сомнения, то можем сравнить конкретный пример по обоим параметрам.

Так все равно, содержимое классов поддерживающих move-семантику(при этом содержащих указатели на массивы, а таких большинство), будет в конечном счете храниться в динамической памяти. move-семантика просто делает это неявно через манипуляции типами-значениями, на самом деле копируя поля-класса-указатели. Не вижу никакого смысла скрывать динамическую память от программиста за этим фасадом из типов-значений, меняя логичное и близкое к железу управление указателями на манипуляции rvalue-reference с хитрыми правилами. Стек же часто абсолютно не подходит, т.к. у многих объектов время жизни не только в пределах функции или блока, как в примере с Session, и для меня именно это определяет чаще всего, на стеке или в куче я выделяю память. emplace_back работает только для конструкторов новых объектов, что накладывает ограничения.
В 'современном C++-стиле' программист оказывается в цепях move-семантики и типов-значений, вместо простых манипуляций указателями. Все это, как ты обьясняешь, необходимо для исключения лишней косвенности. Только в тех случаях, когда приходится оптимизировать программу, либо оптимизируют алгоритм, либо используют ассемблерные simd-инструкции, и тогда точно не нужна C++-абстракция 'тип-значение', а нужны обычные массивы.
Если тебе хватает std::unique_ptr<> — ок, возможно, не буду спорить. Но я бы все же предпочел настоящий сборщик мусора и забыть про разные типы указателей и эти вырвиглазные шаблоны-обертки unique_ptr<Type> в коде вообще.
C++ куда-то ведет коммитет с большой скоростью, и лично я считаю что из низкоуровнего языка его превращают во что-то весьма своеобразное, точно отличное от того, за что он изначально получил популярность.

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

S>Вставь мой код целиком в ответ и покажи где именно нет delete

Fufel* pFufel = new SuperPuperFufel;
try
{
  pFufel->do_something();
}
catch(exception1& e1)
{
    // обработчик
    тут обработчик может бросить исключение
}
catch(exception2& e2)
{
    // обработчик
    тут обработчик может бросить исключение
}
catch(exception3& e3)
{
    // обработчик
    тут обработчик может бросить исключение
}
/*
catch(...)
{
   // не знаю, что делать с исключением
   throw; // пробросить его наверх
   // неспособен понимать какие исключения могут приехать из метода и обработать их все. Уволен.

после увольнения пришёл новый работник и добавил новое исключение в do_something();
}
*/
delete pFufel;

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

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

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

BFE>>после увольнения пришёл новый работник и добавил новое исключение в do_something();
S>И тут же оказался на улице вместе со своим руководителем, допустившим неоттестированный и непроверенный код с багом в прод.

В результате этой естественной эволюции в конторе остались только те, кто использует смарт поинтеры.

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

lpd>Раз объект будет в результате в динамической памяти, то логично сразу там его и выделить, и не мучаться с конструкторами перемещения, которые еще может понадобиться писать вручную только для этого.
И корячиться с дополнительной косвенностью везде где он используется?

lpd>- вместо неявного освобождения unique_ptr<>, лично я предпочту вручную явно вызвать delete. Хотя да, это вопрос вкуса, спорить наверное бесполезно.
Это не вопрос вкуса, это вопрос качества кода.

lpd>- если время жизни объекта неизвестно, то в этом случае shared_ptr может помочь. Но на мой взгляд опциональный сборщик мусора был бы удобнее, чтобы не заботиться о круговых ссылках.
Круговые ссылки часто индикатор косяков в дизайне

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

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

I>>А что будет если тебе надо 2 указателя?
S>Через неделю спросиш "А что будет если надо 1024 указателя?"?
S>Сделаю так, чтобы тут не было указателей.
Значит на стеке. Получается, что автоматическая очистка стека (в т.ч. и объектов на стеке) — это нормально, а автоматическая очистка в куче — плохо?
А в чём разница?

Здравствуйте, Кондраций, Вы писали:

I>>>А что будет если тебе надо 2 указателя?
S>>Через неделю спросиш "А что будет если надо 1024 указателя?"?
S>>Сделаю так, чтобы тут не было указателей.
К>Значит на стеке. Получается, что автоматическая очистка стека (в т.ч. и объектов на стеке) — это нормально, а автоматическая очистка в куче — плохо?
Почему именно на стеке? Что, фантазия всё? )

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

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

S>>>уник это другая

Автор: Sheridan
Дата: 19.12.18

парадигма. "Хрен его знает чтокактут происходит, но этим объектом одновременно обязан владеть ктото один!"

Z>>Серьезно, объект который просто в деструкторе тупо делает "delete" (ну или какую вы хотите операцию,
Z>>например fclose), это "хрен знает что происходит"?
S>Абсолютно верно, ибо программисты не знают где вызвать этот деструктор.

Блин, каждый программист C++ знает где вызывается деструкторы объектов созданных на стеке.
Что в этом сакрального, чем `std::unique_ptr` от других объектов отличается?
Или вы вообще никаких объектов на стеке не создаете? Только примитивные типы достойны выделения на стеке?



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

Любая асинхронная система так работает, посмотрите на использование QEvent в Qt.

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

S>смартпоинтеры это даже не велосипед, это костыль, вставляемый там, где ниасилили обычные поинтеры.

Какое-то воинствующее невежество просто.

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

S>>смартпоинтеры это даже не велосипед, это костыль, вставляемый там, где ниасилили обычные поинтеры.
S>Какое-то воинствующее невежество просто.

Это же Шеридан. Он всегда такой был.

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

lpd>Но медленнее? Для класса сетевого соединения, серьезно? Оптимизировать имеет смысл только самые критичные участки программы — излишняя оптимизация только усложняет код, без заметной пользы.

То что ты предлагаешь это бессмысленное усложнение кода (доп косвенность там, где она нафиг не нужна), по сути premature pessimization.

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

_>И только некоторые "уникальные" C++ программисты умудряются применять обратные техники, замедляющие их изначально быстрый язык.

Да потому что пытаются писать даже не на сабсете С++ а на сабсете С с классами

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

S>Моя позиция: умные указатели нужны когда проект разрастается до состояния "мы нихрена не понимаем уже ничего тут, не знаем какие данные кому сейчас нужны и какое время жизни у объектов, поэтому чтобы не разбираться — возьмём умные указатели".
S>Набрасывайте.

Ну ты, понимаешь, 20 лет ждал чтобы задать этот вопрос? Это флейм для 1998-го года.

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

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

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

lpd>>>ОК, можно так, только я предпочел бы хранить в векторе указатели на Session, чтобы адреса объектов не менялись при расширении вектора. Получается, все-таки нужны указатели.

_>>Ну для начала это будет намного медленнее. Потому что подобная косвенная адресация убивает кэш процессора.

lpd>В данном случае действительно, список удобнее (я зря упомянул вектор, хотя во многих других случаях он может понадобиться).

std::deque

Я вот не могу сказать — перемещает он или нет. Когда-то про него читал, но уже все забыл.

Но.

У класса, которые я в него засовываю через emplace_back, явно запрещены конструкторы/операторы копирования/перемещения.

Значит не перемещает.

А потом я юзаю указатели на элементы.

---
Дополню.

Я тут внимательно посмотрел на этот свой последний случай использования std::deque.

В отладочной версии у его элементов есть счетчик ссылок. То есть снаружи работают со смарт-указателями на эти элементы.

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

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

S>В итоге твой метод переписывается кактотак

После delete имеет смысл всегда обнулять указатель.

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