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

Утечки памяти здесь нет, единственная проблема — globalFoo в какой-то момент начнет указывать на невалидный объект (после того, как отработает деструктор unique_ptr), может быть именно это в исходном тексте называется "alias leak" (т.е. "утекает" не память, а "псевдоним" указателя, мы получаем указатель на наш объект, валидность которого (указателя) мы уже не контролируем)?

Можно проще:

unique_ptr<Foo> pFoo(new Foo());
unique_ptr<Foo> pBar(pFoo.get());

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

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

TB>Покажи, я вот открыл сайт
TB>http://ru.cppreference.com/w/cpp/memory/unique_ptr
TB>и не вижу.

template<

    class T,
    class Deleter = std::default_delete<T> // <- вот он
> class unique_ptr;

да, он не может иметь состояние, как deleter в shared_ptr, но, тем не менее, он есть.

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

AG>

AG>template<

AG>    class T,
AG>    class Deleter = std::default_delete<T> // <- вот он
>> class unique_ptr;
AG>

AG>да, он не может иметь состояние, как deleter в shared_ptr, но, тем не менее, он есть.

Кастомный инициализатор называется Deleter? То ли они такие затейники, то ли кто-то невнимательно читает.

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

W>Угу. Этот сценарий поддерживается отлично.

W>Но что ты будешь делать если у тебя уже есть голый указатель (которые, например, сторонняя библиотека тебе вернула)? Как его завернёшь в unique_ptr чтобы контролировать время жизни? Не через make_unique ведь. Вот тут и нужен вызов конструктора.

Так я же не спорю, я отвечаю на вопрос:
>а какие алтьтернативы вы предлагаете для создания проинициализированного unique_ptr?

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

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

__>>а какие алтьтернативы вы предлагаете для создания проинициализированного unique_ptr?
TB>make_unique же

он только создает, а не инициализирует уже существующим (соответственно, не будет возможности заворачивать сырые указатели)

TB> Или это опять легаси-говно?
Ты далеко лошадь припарковал, Д'артаньян?

Объясните, печему тут будет утечка пямяти

void f(Foo * pf) {
    globalFoo = pf; // creates a global alias
}

unique_ptr<Foo> pFoo(new Foo());
f(pFoo.get()); // leaks an alias

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


J>Утечки памяти здесь нет, единственная проблема — globalFoo в какой-то момент начнет указывать на невалидный объект (после того, как отработает деструктор unique_ptr), может быть именно это в исходном тексте называется "alias leak" (т.е. "утекает" не память, а "псевдоним" указателя, мы получаем указатель на наш объект, валидность которого (указателя) мы уже не контролируем)?

Спасибо, я тоже так и думал, смутило слово leak

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

TB>Можно проще:
TB>

TB>unique_ptr<Foo> pFoo(new Foo());
TB>unique_ptr<Foo> pBar(pFoo.get());
TB>

TB>Правда мой пример немного про другое: про то, что какого-то хрена конструктор из указателя сделан публичным.

а какие алтьтернативы вы предлагаете для создания проинициализированного unique_ptr?

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

__>а какие алтьтернативы вы предлагаете для создания проинициализированного unique_ptr?

make_unique?

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

__>а какие алтьтернативы вы предлагаете для создания проинициализированного unique_ptr?
make_unique же

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

__>>а какие алтьтернативы вы предлагаете для создания проинициализированного unique_ptr?

N>make_unique?

Но функция std::make_unique уже существует и у неё другая семантика.

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

W>Но функция std::make_unique уже существует и у неё другая семантика.

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

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

__>>>а какие алтьтернативы вы предлагаете для создания проинициализированного unique_ptr?

N>>make_unique?

W>Но функция std::make_unique уже существует и у неё другая семантика.

Ну он же создаёт проинициализированный unique_ptr без работы с голыми указателями?

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

N>Ну он же создаёт проинициализированный unique_ptr без работы с голыми указателями?

Угу. Этот сценарий поддерживается отлично.

Но что ты будешь делать если у тебя уже есть голый указатель (которые, например, сторонняя библиотека тебе вернула)? Как его завернёшь в unique_ptr чтобы контролировать время жизни? Не через make_unique ведь. Вот тут и нужен вызов конструктора.

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

W>Но что ты будешь делать если у тебя уже есть голый указатель (которые, например, сторонняя библиотека тебе вернула)? Как его завернёшь в unique_ptr чтобы контролировать время жизни? Не через make_unique ведь. Вот тут и нужен вызов конструктора.

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

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

__>он только создает, а не инициализирует уже существующим (соответственно, не будет возможности заворачивать сырые указатели)

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

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

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

__>>он только создает, а не инициализирует уже существующим (соответственно, не будет возможности заворачивать сырые указатели)

TB>Зачем заворачивать сырые указатели? Если их возвращает АПИ, то нужен кастомный делетер, иначе пороховая бочка.

а откуда пороховая бочка-то? в таких случаях возвращаемые указатели на объекты изначально предполагают их удаление по стандартному delete pObj.

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

__>а откуда пороховая бочка-то? в таких случаях возвращаемые указатели на объекты изначально предполагают их удаление по стандартному delete pObj.

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

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

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

__>>а откуда пороховая бочка-то? в таких случаях возвращаемые указатели на объекты изначально предполагают их удаление по стандартному delete pObj.

TB>А потому что хз, чем это АПИ память выделило. Если же оно внутри именно вызывает стандартный нью, то хренли ему сразу не вернуть юник? Или это опять легаси-говно?

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

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

TB> Короче, пока в юнике нельзя задавать кастомный инициализатор

Почему нельзя?

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

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

TB>> Короче, пока в юнике нельзя задавать кастомный инициализатор

AG>Почему нельзя?

Покажи, я вот открыл сайт
http://ru.cppreference.com/w/cpp/memory/unique_ptr
и не вижу.

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

TB>Будешь свой юник с кастомным делетером делать? Я хз, нафиг он нужен без кастомного инитиализера, пороховая бочка какая-то. Может, просто без юника обёртку сделать?

Если у объекта перекрыт метод operator delete или виртуальный деструктор, библиотека может обеспечить прозрачное удаление по delete pObject

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

TB>> Или это опять легаси-говно?
DA>Ты далеко лошадь припарковал, Д'артаньян?

Что тебе не нравится? Ради того, чтобы сэкономить буквы на один специфичный случай, разрешить взрывоопасный конструктор — это ок?

TB>>> Или это опять легаси-говно?
DA>>Ты далеко лошадь припарковал, Д'артаньян?

TB>Что тебе не нравится? Ради того, чтобы сэкономить буквы на один специфичный случай, разрешить взрывоопасный конструктор — это ок?
Я про легаси спрашивал.

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

TB>>>> Или это опять легаси-говно?
DA>>>Ты далеко лошадь припарковал, Д'артаньян?

TB>>Что тебе не нравится? Ради того, чтобы сэкономить буквы на один специфичный случай, разрешить взрывоопасный конструктор — это ок?
DA>Я про легаси спрашивал.

Я про легаси и ответил.
Если библиотека возвращает указатель на выделенный ей же элемент, то обернуть можно.
Не, если предыдущие говнокодеры уже написали через new, то что ж, теперь вообще любую хрень оправдывать?