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

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

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

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

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

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


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

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

Можно проще:

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

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

Здравствуйте, 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 ведь. Вот тут и нужен вызов конструктора.

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

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

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

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

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

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

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

__>>а какие алтьтернативы вы предлагаете для создания проинициализированного unique_ptr?
TB>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
и не вижу.