Не раз слышал, что рекомендуется использовать unique_ptr везде, где только можно вместо shared_ptr, из-за "тяжеловесности" последнего.
А в чем заключается оверхед?

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

А>Не раз слышал, что рекомендуется использовать unique_ptr везде, где только можно вместо shared_ptr, из-за "тяжеловесности" последнего.
А>А в чем заключается оверхед?

в атомарности счетчика ссылок.
еще sizeof(shared_ptr<T>) == 2 * sizeof(void*)

А>Не раз слышал, что рекомендуется использовать unique_ptr везде, где только можно вместо shared_ptr, из-за "тяжеловесности" последнего.
у shared_ptr и unique_ptr прежде всего разная семантика, поэтому вопрос об "оверхедах" вообще не должен стоять, т.к. там где достаточно unique_ptr, не надо использовать shared_ptr, это сбивает с толку, и соответственно там где нужно использовть shared_ptr не надо использовать unique_ptr ( за этим уже конечно компилятор проследит )

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

А>Не раз слышал, что рекомендуется использовать unique_ptr везде, где только можно вместо shared_ptr, из-за "тяжеловесности" последнего.
А>А в чем заключается ове
В 95% случаев использование shared ptr свидетельствует о недостаточной квалификации разработчика.

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

А>>Не раз слышал, что рекомендуется использовать unique_ptr везде, где только можно вместо shared_ptr, из-за "тяжеловесности" последнего.

V>В 95% случаев использование shared ptr свидетельствует о недостаточной квалификации разработчика.

А что исползуют квалифицированные разработчики в тех случаях, где разработчики с недостаточной квалификацией используют shared_ptr?

V>>В 95% случаев использование shared ptr свидетельствует о недостаточной квалификации разработчика.
bnk>А что исползуют квалифицированные разработчики в тех случаях, где разработчики с недостаточной квалификацией используют shared_ptr?
только хардкор intrusive_ptr

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

А>Не раз слышал, что рекомендуется использовать unique_ptr везде, где только можно вместо shared_ptr, из-за "тяжеловесности" последнего.
А>А в чем заключается оверхед?
в том что для shared_ptr вызывается new.
используй intrusive_ptr

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

А>>>Не раз слышал, что рекомендуется использовать unique_ptr везде, где только можно вместо shared_ptr, из-за "тяжеловесности" последнего.
V>>В 95% случаев использование shared ptr свидетельствует о недостаточной квалификации разработчика.
bnk>А что исползуют квалифицированные разработчики в тех случаях, где разработчики с недостаточной квалификацией используют shared_ptr?

Типов проблем, для решения которых они по ошибке используют shared_ptr, много. Поэтому альтернатив тоже много:
1. Никаких owning ptr'ов, обычные scoped объекты
2. RVO, NRVO, move semantic
3. Boost.Variant-like
4. Гетерогенные контейнеры
5. Type-erasure, а-ля std::function
6. scoped_ptr
7. unique_ptr
8. ref counting без межпоточной синхронизации (например, на базе intrusive_ptr)

P.S. Помимо того, что shared_ptr'ом часто злоупотребляют, им ещё и пользуются неоптимально. Например не используют make_shared, делают лишние копии (с атомарным передёргивание внутри) когда достаточно move или const&.

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

V>В 95% случаев использование shared ptr свидетельствует о недостаточной квалификации разработчика.

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

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

IRO>Здравствуйте, Аноним, Вы писали:

А>>Не раз слышал, что рекомендуется использовать unique_ptr везде, где только можно вместо shared_ptr, из-за "тяжеловесности" последнего.
А>>А в чем заключается оверхед?
IRO>в том что для shared_ptr вызывается new.
что? какой еще new?
IRO>используй intrusive_ptr

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

EP>8. ref counting без межпоточной синхронизации (например, на базе intrusive_ptr)

что имелось здесь ввиду? во-первых у shared_ptr-а есть однопоточная версия без "оверхедов", а во-вторых в многопоточной где возможно используются атомарные операции. В чём здесь преимущество intrusive_ptr'а?

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

IRO>>в том что для shared_ptr вызывается new.
A>что? какой еще new?
Тот же, который в vector и string используется.

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

EP>>8. ref counting без межпоточной синхронизации (например, на базе intrusive_ptr)
A>что имелось здесь ввиду? во-первых у shared_ptr-а есть однопоточная версия без "оверхедов"

Которая включается макросом? То есть которую нельзя использовать одновременно с многопоточной из-за ODR?

A>а во-вторых в многопоточной где возможно используются атомарные операции.

Что ты имеешь в виду? Ты про то, что атомарные дешевле mutex'а? Так они всё всё равно не бесплатные.

A>В чём здесь преимущество intrusive_ptr'а?

На базе intrusive_ptr можно сделать ref counting без межпоточной синхронизации (атомарные операции это тоже межпоточная синхронизация).

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

J>Тот же, который в vector и string используется.
т.е. shared_ptr сам внутрях создает объекты vector и string? оО
[irony]тогда да, такое использовать не стОит.[/irony]

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

V>>В 95% случаев использование shared ptr свидетельствует о недостаточной квалификации разработчика.
A>я конечно понимаю, что дурак может и стеклянный половой орган разбить и руки порезать, но про "95%" это либо твоё личное окружение ( "мне вас жаль" ) либо откуда статистика?

Эту тему даже Страуструп в своей презентации обыгрывал: Going Native 2012 keynote, 33:04.
Мол заменяют голый new (который, например, поставили из-за Java привычки), на shared_ptr, хотя достаточно unique_ptr, или даже вообще обычного scoped объекта.

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

A>что? какой еще new?
shared_ptr помимо указателя на объект хранит еще и указатель на счетчик ссылок. Самый первый shared_ptr создает счетчик ссылок через вызов new.

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

A>>что? какой еще new?
A>shared_ptr помимо указателя на объект хранит еще и указатель на счетчик ссылок. Самый первый shared_ptr создает счетчик ссылок через вызов new.

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

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

EP>На базе intrusive_ptr можно сделать ref counting без межпоточной синхронизации (атомарные операции это тоже межпоточная синхронизация).
А где почитать про переносимый ref counting без межпоточной синхронизации?

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

EP>>На базе intrusive_ptr можно сделать ref counting без межпоточной синхронизации (атомарные операции это тоже межпоточная синхронизация).
BFE>А где почитать про переносимый ref counting без межпоточной синхронизации?

Если известно, что твои ref-counting ptrs будут гулять только по одному потоку, то межпоточная синхронизация не нужна.

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

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

J>>Тот же, который в vector и string используется.
X>т.е. shared_ptr сам внутрях создает объекты vector и string? оО
Странная у тебя логика. А vector внутри себя использует new для создания vector'а ?
Ты ж вроде занимаешся сборкой какого то компилятора? Ну загляни в сорцы тамошнего stl, увидишь зачем там дин память нужна.