Здравствуйте, _NN_, Вы писали:
_NN>Еще в древние времена С++98 вместо явного вызова delete используется деструктор , который вызывает delete внутри.
_NN>Новый C++ дает возможность отказаться и от 'new' за счет функций вида make_***. _NN>Преимущество нет проблем с утечками памяти при исключениях.
_NN>Т.е. эти конструкции нужны на более низком уровне, только чтобы написать обертки.
_NN>Согласны ли вы, что 'new' в обычном коде тоже устарел ?
Конечно. Оно все устарело "еще в древние времена С++98" с приходом буста — все эти make_*** оттуда.
Только устарело — не совсем правильное слово. Оно просто спустилось на уровень ниже дефолтного, в мрачные подземелья unsafe-кода, вместе с кастами голых указателей и прочими радостями. Где ему и место, в общем-то.
Здравствуйте, _NN_, Вы писали:
_NN>Еще в древние времена С++98 вместо явного вызова delete используется деструктор , который вызывает delete внутри.
_NN>Новый C++ дает возможность отказаться и от 'new' за счет функций вида make_***. _NN>Преимущество нет проблем с утечками памяти при исключениях.
_NN>Т.е. эти конструкции нужны на более низком уровне, только чтобы написать обертки.
_NN>Согласны ли вы, что 'new' в обычном коде тоже устарел ?
Для тех кому пофиг на оверхед new/delete уже примерно лет 10 назад устарели.
А для тех кому не пофиг, не устарели и скорее всего никогда не устареют.
С++ он разный, такие дела.
SVZ>Вообще-то по Стандарту объект не может быть нулевого размера. Значит даже функтор будет занимать хотя бы один 1 байт, плюс выравнивание...
ну все не так просто. смотри упомянутый выше EBO.
SVZ>Так что тут что указатель на функцию, что функтор — разницы нет. Может оптимизатор что-то поправит, но я сомневаюсь.
А я нет, потому что проверил. И gcc, студия (2013ая) убирают этот байт.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, skeptic, Вы писали:
S>>Для тех кому пофиг на оверхед new/delete уже примерно лет 10 назад устарели. A>синтаксический оверхед, да?
В эти "мэйки" можно чего угодно внутрь запихать.
Да и любой смарт указатель это всё таки больше чем
просто обёртка, не понятно с чем ты тут не согласен?
Что оверхед мал и с ним можно не считаться?
Так я с этим и не спорю — в моих задачах он мал,
но я вполне могу допустить существование ненулевого множества людей
для чьих задач он будет существенен.
Здравствуйте, Jack128, Вы писали:
KO>>А я нигде не утверждал, что my_cool_custom_deleter это указатель на функцию.
J>а коду my_cool_custom_deleter_functor на это пофиг. Функция, функтор, без разницы, главное чтобы можно было вызвать my_cool_custom_deleter(x);
А коду, которому придется использовать my_cool_custom_deleter_functor может быть не пофиг.
J>>>Я обернул этот делетер в ламбду. По сути лямбда — это функтор, структура с перекрытым оператом (). так эта лямбда не захватывает переменных(у неё пустой список []) , то у структуры нету полей. А раз так, то и в unique_ptr нечему хранится, никакого оверхеда нет.
KO>>Только теперь, объект deleter'а, по-сути, гвоздями прибит к типу указателя.
J>и? Примера демонстрирующего проблему я так понимаю ты не напишешь?
Здравствуйте, skeptic, Вы писали:
S>Да и любой смарт указатель это всё таки больше чем S>просто обёртка, не понятно с чем ты тут не согласен?
а какой оверхед несет unique_ptr ??
Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради...
указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела.
_____________________
С уважением,
Stanislav V. Zudin
J>>и внезапно все накладные расходы исчезают...
SVZ>Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради... SVZ>указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела.
В реализации для gcc хранится (только, конечно, не указатель а сам объект deleter'а). И в C++11 нельзя использовать decltype для лямбд. Можно, конечно, запилить, класс, который будет хранить deleter в статическом поле и избавиться от оверхеда, но, у этого решения есть, свои, очевидные, недостатки.
X>lambda.cpp: In function ‘int main()’:
X>lambda.cpp:4:19: error: use of deleted function ‘main()::__lambda0::<lambda>()’
X> decltype(lambda) lb;
X> ^
X>lambda.cpp:3:17: note: a lambda closure type has a deleted default constructor
X> auto lambda = [](){return 33;};
X> ^
Здравствуйте, _NN_, Вы писали:
_NN>>>Еще в древние времена С++98 вместо явного вызова delete используется деструктор , который вызывает delete внутри. _NN>>>Новый C++ дает возможность отказаться и от 'new' за счет функций вида make_***. NB>>make_*** могет placement new? _NN>Нет , ну так в случае placement new нет проблем с утечкой памяти при исключении как при обычном new.
А в стандарте что-то написано про allocate_shared:
template <class T, class Alloc, class... Args> shared_ptr<T> allocate_shared (const Alloc& alloc, Args&&... args);
Здравствуйте, jazzer, Вы писали:
J>Конечно. Оно все устарело "еще в древние времена С++98" с приходом буста — все эти make_*** оттуда.
всетаки без variadic templates все эти make самому писать было сложно.
Здравствуйте, skeptic, Вы писали:
S>>>Для тех кому пофиг на оверхед new/delete уже примерно лет 10 назад устарели. A>>синтаксический оверхед, да?
S>В эти "мэйки" можно чего угодно внутрь запихать. S>Да и любой смарт указатель это всё таки больше чем S>просто обёртка, не понятно с чем ты тут не согласен? S>Что оверхед мал и с ним можно не считаться? S>Так я с этим и не спорю — в моих задачах он мал, S>но я вполне могу допустить существование ненулевого множества людей S>для чьих задач он будет существенен.
ну-ка расскажи мне про оверхед unique_ptr, вдруг я что-то новое узнаю
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, skeptic, Вы писали:
S>>Да и любой смарт указатель это всё таки больше чем S>>просто обёртка, не понятно с чем ты тут не согласен? J>а какой оверхед несет unique_ptr ??
deleter.
На всякий случай, замечу, что я согласен с тем, что оверхед будет малозаметным или вовсе отсутствовать во многих (если не в большинстве) случаев.
Здравствуйте, k.o., Вы писали:
S>>>Да и любой смарт указатель это всё таки больше чем S>>>просто обёртка, не понятно с чем ты тут не согласен? J>>а какой оверхед несет unique_ptr ??
KO>deleter.
зависит от реализации. EBO все-же работает.
KO>На всякий случай, замечу, что я согласен с тем, что оверхед будет малозаметным или вовсе отсутствовать во многих (если не в большинстве) случаев.
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, k.o., Вы писали:
KO>>Или надо было еще сказать, что иногда может понадобиться что-то более сложное чем default_deleter?
J>а без разницы. сам себе unique_ptr не несет оверхеда. Даже с кастомным делетром. но если ты можешь показать код, который бы нес оверхед, было конечно интересно, но я в такое не верю.
Если ты считаешь, что хранение deleter'а в unique_ptr никогда и ни при каких обстоятельствах не несет оверхеда, то, боюсь, доказывать что-то бесполезно, а если ты так не считаешь, то и обсуждать нечего.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, k.o., Вы писали:
KO>>Или надо было еще сказать, что иногда может понадобиться что-то более сложное чем default_deleter?
J>Если вдруг понадобилось "что-то более сложное", то, наверное, оно понадобилось бы и без умных указателей?
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, k.o., Вы писали:
KO>>>Или надо было еще сказать, что иногда может понадобиться что-то более сложное чем default_deleter?
J>>Если вдруг понадобилось "что-то более сложное", то, наверное, оно понадобилось бы и без умных указателей?
KO>
J>>и внезапно все накладные расходы исчезают...
SVZ>Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради... SVZ>указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела.
в unique_ptr хранится не указатель, а сам делетер. в часном случае (который привел k.o.) делетер — это указатель на функцию. Конечно в этом случае мы имеет 4 профуканных байта.
Я обернул этот делетер в ламбду. По сути лямбда — это функтор, структура с перекрытым оператом (). так эта лямбда не захватывает переменных(у неё пустой список []) , то у структуры нету полей. А раз так, то и в unique_ptr нечему хранится, никакого оверхеда нет.
Здравствуйте, Jack128, Вы писали:
SVZ>>Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради... SVZ>>указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела. J>в unique_ptr хранится не указатель, а сам делетер. в часном случае (который привел k.o.) делетер — это указатель на функцию. Конечно в этом случае мы имеет 4 профуканных байта.
А я нигде не утверждал, что my_cool_custom_deleter это указатель на функцию.
J>Я обернул этот делетер в ламбду. По сути лямбда — это функтор, структура с перекрытым оператом (). так эта лямбда не захватывает переменных(у неё пустой список []) , то у структуры нету полей. А раз так, то и в unique_ptr нечему хранится, никакого оверхеда нет.
Только теперь, объект deleter'а, по-сути, гвоздями прибит к типу указателя.
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, Jack128, Вы писали:
SVZ>>>Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради... SVZ>>>указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела. J>>в unique_ptr хранится не указатель, а сам делетер. в часном случае (который привел k.o.) делетер — это указатель на функцию. Конечно в этом случае мы имеет 4 профуканных байта.
KO>А я нигде не утверждал, что my_cool_custom_deleter это указатель на функцию.
а коду my_cool_custom_deleter_functor на это пофиг. Функция, функтор, без разницы, главное чтобы можно было вызвать my_cool_custom_deleter(x);
J>>Я обернул этот делетер в ламбду. По сути лямбда — это функтор, структура с перекрытым оператом (). так эта лямбда не захватывает переменных(у неё пустой список []) , то у структуры нету полей. А раз так, то и в unique_ptr нечему хранится, никакого оверхеда нет.
KO>Только теперь, объект deleter'а, по-сути, гвоздями прибит к типу указателя.
и? Примера демонстрирующего проблему я так понимаю ты не напишешь?
KO>все-таки, есть некоторая разница с хранением my_cool_custom_deleter в объектах unique_ptr?
если my_cool_custom_deleter это функция, адрес которой известен статически, она не будет храниться в unique_ptr.
если это указатель на функцию или объект — то не надо использовать unique_ptr, он для этого не предназначен
unique_ptr это аналог T*, или T[], или кортежей (T*, Deleter) или (T[], Deleter),
если ты его комбинируешь с вектором получается что-то вроде (T*, Deleter)[], это совсем не (T*[], Deleter) .
просто не надо использовать вещи для чего они не предназначены, и не будет оверхеда
Здравствуйте, night beast, Вы писали:
NB>предположим, что my_cool_custom_deleter -- мембер класса: NB>
NB>template< typename Deleter >
NB>struct foo {
NB> Deleter my_cool_custom_deleter;
NB> // как определить вектор мембером?
NB> void test ( ) {
NB> auto my_cool_custom_deleter_functor = ??;
NB> std::vector<std::unique_ptr<X, decltype(my_cool_custom_deleter_functor)>> c;
NB> }
NB>};
NB>
Передавай его напрямую, по значению. Если он stateless — то на размер не повлияет, если stateful — то естественно повлияет.
Но если у тебя stateful deleter — тебе его пришлось бы таскать вместе с указателем и без unique_ptr. То есть unique_ptr никакого нового оверхеда тут не добавляет.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
NB>>предположим, что my_cool_custom_deleter -- мембер класса:
NB>>template< typename Deleter >
NB>>struct foo {
NB>> Deleter my_cool_custom_deleter;
NB>> // как определить вектор мембером?
NB>> void test ( ) {
NB>> auto my_cool_custom_deleter_functor = ??;
NB>> std::vector<std::unique_ptr<X, decltype(my_cool_custom_deleter_functor)>> c;
NB>> }
NB>>};
EP>Передавай его напрямую, по значению. Если он stateless — то на размер не повлияет,
код какой?
EP>если stateful — то естественно повлияет. EP>Но если у тебя stateful deleter — тебе его пришлось бы таскать вместе с указателем и без unique_ptr. То есть unique_ptr никакого нового оверхеда тут не добавляет.
дык о том и речь. он stateful, но в пределах вектора/класса/группы объектов.
допустим, в класс передается аллокатор, а в делетере хранится указатель на него.
естественно, таскать его с каждым элементом вектора -- лишний оверхед.
Здравствуйте, skeptic, Вы писали:
S>1. те кто работает на низком уровне в массе своей всё равно будут сидеть на сырых указателях
Зачем? S>2. далеко не у всех есть и в скором времени будет доступ к компиляторам реализующим последний стандарт
А что, без него умные указатели не заработают?
Здравствуйте, _NN_, Вы писали:
_NN>Еще в древние времена С++98 вместо явного вызова delete используется деструктор , который вызывает delete внутри.
_NN>Новый C++ дает возможность отказаться и от 'new' за счет функций вида make_***. _NN>Преимущество нет проблем с утечками памяти при исключениях.
_NN>Т.е. эти конструкции нужны на более низком уровне, только чтобы написать обертки.
_NN>Согласны ли вы, что 'new' в обычном коде тоже устарел ?
да!
уже два года как устарели.
ЗЫ: на cplusplus куча бреда и ошибок, на него лучше не ссылаться.
Здравствуйте, skeptic, Вы писали:
S>Для тех кому пофиг на оверхед new/delete уже примерно лет 10 назад устарели.
синтаксический оверхед, да?
S>С++ он разный, такие дела.
и не все его могут выучить, ага
Здравствуйте, _NN_, Вы писали:
_NN>Еще в древние времена С++98 вместо явного вызова delete используется деструктор , который вызывает delete внутри.
_NN>Новый C++ дает возможность отказаться и от 'new' за счет функций вида make_***.
make_*** могет placement new?
_NN>Преимущество нет проблем с утечками памяти при исключениях.
_NN>Т.е. эти конструкции нужны на более низком уровне, только чтобы написать обертки.
_NN>Согласны ли вы, что 'new' в обычном коде тоже устарел ?
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, _NN_, Вы писали:
_NN>>Еще в древние времена С++98 вместо явного вызова delete используется деструктор , который вызывает delete внутри.
_NN>>Новый C++ дает возможность отказаться и от 'new' за счет функций вида make_***.
NB>make_*** могет placement new?
Нет , ну так в случае placement new нет проблем с утечкой памяти при исключении как при обычном new.
И обычно он используется в обертке, а не в обычном коде.
Конечно смотря что делать, в коде проекта у нас есть места с placement new для интерпретации памяти через класс, но вряд ли это показатель
_NN>>Согласны ли вы, что 'new' в обычном коде тоже устарел ? NB>если используется Qt, то без new будет непросто.
Я о том, что 'new' уходит на уровень ниже.
И в Qt , наверное, также можно сделать T make_Qt(Args&&... args) , что позволяет легко решить проблему с исключениями и утечками памяти.
Здравствуйте, _NN_, Вы писали:
_NN>Конечно смотря что делать, в коде проекта у нас есть места с placement new для интерпретации памяти через класс, но вряд ли это показатель
_NN>>>Согласны ли вы, что 'new' в обычном коде тоже устарел ? NB>>если используется Qt, то без new будет непросто. _NN>Я о том, что 'new' уходит на уровень ниже. _NN>И в Qt , наверное, также можно сделать T make_Qt(Args&&... args) , что позволяет легко решить проблему с исключениями и утечками памяти.
там чуть другой мезанизм. при создании передается указатель на родитель, а родитель при разрушении сам всех потомков удаляет.
ну и сами объекты не копиконструктивные.
Здравствуйте, night beast, Вы писали:
NB>там чуть другой мезанизм. при создании передается указатель на родитель, а родитель при разрушении сам всех потомков удаляет.
А как решается ситуация:
new Child(new Parent(), FunctionMayThrowException());
Или просто такой ситуации быть не может ?
NB>ну и сами объекты не копиконструктивные.
Я имел ввиду T* конечно
Здравствуйте, _NN_, Вы писали:
NB>>там чуть другой мезанизм. при создании передается указатель на родитель, а родитель при разрушении сам всех потомков удаляет. _NN>А как решается ситуация: _NN>
NB>не может. то есть можно, конечно, выдумать пример, но как правило парент уже есть.
Т.е. всегда есть порядок, сначала внешний объект, потом внутренние и т.д ?
auto c1 = new Child1(Root);
auto c2 = new Child2(c1);
Здесь конечно проблемы нет, кроме 'delete' который никто не вызовет при исключении
А если передавать параметры, то может быть.
Если конечно есть исключения Qt API =)
Типа
auto c1 = new Child(Root.GetFirstChild(), new SomeParameter());
Здравствуйте, _NN_, Вы писали:
_NN>Т.е. всегда есть порядок, сначала внешний объект, потом внутренние и т.д ?
там вообще все очень странно спроектированно. Qt умудряется применять delete и к объектам созданным на стеке =)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, k.o., Вы писали:
KO>>На всякий случай, замечу, что я согласен с тем, что оверхед будет малозаметным или вовсе отсутствовать во многих (если не в большинстве) случаев.
_NN>Если не нужен deleter, то вместо unique_ptr можно взять другой умный указатель ( my_simple_unique_ptr ) без этой поддержки и будет без оверхеда.
а если нужен? только один и тот же для большого количества объектов? В любом случае, вопрос был про оверхед unique_ptr, а не my_simple_unique_ptr, вместо которого, в тех редких случаях когда ни unique ни shared ни intrusive ptr'ы не подходят, проще использовать обычный указатель.
Здравствуйте, _NN_, Вы писали:
NB>>не может. то есть можно, конечно, выдумать пример, но как правило парент уже есть. _NN>Т.е. всегда есть порядок, сначала внешний объект, потом внутренние и т.д ?
_NN>
_NN>auto c1 = new Child1(Root);
_NN>auto c2 = new Child2(c1);
_NN>
_NN>Здесь конечно проблемы нет, кроме 'delete' который никто не вызовет при исключении
чей delete? у чайлдов root вызовет, у рута -- твоя забота. хочешь в юник положи, хочешь еще как.
_NN>А если передавать параметры, то может быть.
_NN>Если конечно есть исключения Qt API =)
не припоминаю, чтобы приходилось когда-нибудь ловить исключения из Qt
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, k.o., Вы писали:
S>>>>Да и любой смарт указатель это всё таки больше чем S>>>>просто обёртка, не понятно с чем ты тут не согласен? J>>>а какой оверхед несет unique_ptr ??
KO>>deleter.
NB>зависит от реализации. EBO все-же работает.
KO>>На всякий случай, замечу, что я согласен с тем, что оверхед будет малозаметным или вовсе отсутствовать во многих (если не в большинстве) случаев.
Или надо было еще сказать, что иногда может понадобиться что-то более сложное чем default_deleter?
Здравствуйте, k.o., Вы писали:
KO>Или надо было еще сказать, что иногда может понадобиться что-то более сложное чем default_deleter?
а без разницы. сам себе unique_ptr не несет оверхеда. Даже с кастомным делетром. но если ты можешь показать код, который бы нес оверхед, было конечно интересно, но я в такое не верю.
J>>и внезапно все накладные расходы исчезают...
KO>ну, если, к ним не относить расходы на приведение этого кода, хотя бы, в компилируемое состояние, то ты, безусловно прав.
афигеть. точно с запятой забыл.
Надеюсь так устроит ???
#include <iostream>
#include <memory>
#include <vector>
struct X{ int my_data; };
void my_cool_custom_deleter(X *x) { delete x; }
auto my_cool_custom_deleter_functor = [](X* x) { my_cool_custom_deleter(x); };
std::vector<std::unique_ptr<X, decltype(my_cool_custom_deleter_functor)>> c;
int main()
{
std::cout << "size of unique_ptr with non def deleter = " << sizeof(std::unique_ptr<int, decltype(my_cool_custom_deleter_functor)>) << std::endl;
}
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, k.o., Вы писали:
KO>>И в C++11 нельзя использовать decltype для лямбд.
J>Где это написано? GCC компилит.
Ну GCC не показатель, но ты прав, это я с другим случаем спутал.
A lambda-expression shall not appear in an unevaluated operand (Clause 5).
Здравствуйте, Jack128, Вы писали:
J>Где это написано? GCC компилит.
4.8.1 не компилит:
int main() {
auto lambda = [](){return 33;};
decltype(lambda) lb;
return lb();
}
результат:
lambda.cpp: In function ‘int main()’:
lambda.cpp:4:19: error: use of deleted function ‘main()::__lambda0::<lambda>()’
decltype(lambda) lb;
^
lambda.cpp:3:17: note: a lambda closure type has a deleted default constructor
auto lambda = [](){return 33;};
^
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
J>>>и внезапно все накладные расходы исчезают...
SVZ>>Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради... SVZ>>указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела. J>в unique_ptr хранится не указатель, а сам делетер. в часном случае (который привел k.o.) делетер — это указатель на функцию. Конечно в этом случае мы имеет 4 профуканных байта. J>Я обернул этот делетер в ламбду. По сути лямбда — это функтор, структура с перекрытым оператом (). так эта лямбда не захватывает переменных(у неё пустой список []) , то у структуры нету полей. А раз так, то и в unique_ptr нечему хранится, никакого оверхеда нет.
Вообще-то по Стандарту объект не может быть нулевого размера. Значит даже функтор будет занимать хотя бы один 1 байт, плюс выравнивание...
Так что тут что указатель на функцию, что функтор — разницы нет. Может оптимизатор что-то поправит, но я сомневаюсь.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Jack128, Вы писали:
J>>выделенное ни на какие мысли не наводит? X>я не спрашивал почему не компилится, я подтвердил что не компилится.
так ты же потребовал конструктор по умолчанию, а для deleter'а, такого требования, вроде бы, нет.
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, Jack128, Вы писали:
KO>>>А я нигде не утверждал, что my_cool_custom_deleter это указатель на функцию.
J>>а коду my_cool_custom_deleter_functor на это пофиг. Функция, функтор, без разницы, главное чтобы можно было вызвать my_cool_custom_deleter(x);
KO>А коду, которому придется использовать my_cool_custom_deleter_functor может быть не пофиг.
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, k.o., Вы писали:
KO>>Здравствуйте, Jack128, Вы писали:
KO>>>>А я нигде не утверждал, что my_cool_custom_deleter это указатель на функцию.
J>>>а коду my_cool_custom_deleter_functor на это пофиг. Функция, функтор, без разницы, главное чтобы можно было вызвать my_cool_custom_deleter(x);
KO>>А коду, которому придется использовать my_cool_custom_deleter_functor может быть не пофиг.
J>а тут что не так?
ну так, тот же самый пример, объекты deleter'ов разные, а остальной код один и тот-же.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, k.o., Вы писали:
A>если my_cool_custom_deleter это функция, адрес которой известен статически, она не будет храниться в unique_ptr. A>если это указатель на функцию или объект — то не надо использовать unique_ptr, он для этого не предназначен
а обосновать?
A>unique_ptr это аналог T*, или T[], или кортежей (T*, Deleter) или (T[], Deleter), A>если ты его комбинируешь с вектором получается что-то вроде (T*, Deleter)[], это совсем не (T*[], Deleter) .
A>просто не надо использовать вещи для чего они не предназначены, и не будет оверхеда
Так в чем же проблема с использованием unique_ptr и объекта deleter'а? в оверхеде?
Здравствуйте, k.o., Вы писали:
KO>так ты же потребовал конструктор по умолчанию, а для deleter'а, такого требования, вроде бы, нет.
ничего я не требовал. мне вообще это не нужно.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, k.o., Вы писали:
KO>>так ты же потребовал конструктор по умолчанию, а для deleter'а, такого требования, вроде бы, нет. X>ничего я не требовал. мне вообще это не нужно.
SVZ>Вообще-то по Стандарту объект не может быть нулевого размера. Значит даже функтор будет занимать хотя бы один 1 байт, плюс выравнивание... SVZ>Так что тут что указатель на функцию, что функтор — разницы нет. Может оптимизатор что-то поправит, но я сомневаюсь.
Там помнится хитро используется наследование. В результате sizeof(unique_ptr<void>)==sizeof(void*)
J>>>и внезапно все накладные расходы исчезают...
KO>>ну, если, к ним не относить расходы на приведение этого кода, хотя бы, в компилируемое состояние, то ты, безусловно прав.
J>афигеть. точно с запятой забыл.
J>Надеюсь так устроит ???
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, skeptic, Вы писали:
S>>Да и любой смарт указатель это всё таки больше чем S>>просто обёртка, не понятно с чем ты тут не согласен? J>а какой оверхед несет unique_ptr ??
Разговор был не про уник в частности, а про смарт поинтеры в целом.
Разговор был в контексте — да, смарт поинтеры отжимают долю у raw, но полностью не отожмут никогда,
разве что C++ станет очередным C#, но это уже совсем другая история. Вот с чем тут можно спорить?
Если говорить про уник, то да, это замена raw указателям, но
1. те кто работает на низком уровне в массе своей всё равно будут сидеть на сырых указателях
2. далеко не у всех есть и в скором времени будет доступ к компиляторам реализующим последний стандарт
А ещё интересно, а чего это вы тут все в ветке за уник прицепились? Есть же другие замечательные — шаред например.
Как дети, чё не скажи — 100500 слов протеста и литр слюны...
Здравствуйте, night beast, Вы писали:
NB>>>предположим, что my_cool_custom_deleter -- мембер класса: NB>
NB>>>template< typename Deleter >
NB>>>struct foo {
NB>>> Deleter my_cool_custom_deleter;
NB>>> // как определить вектор мембером?
NB>
std::vector<std::unique_ptr<X, Deleter>> c;
EP>>если stateful — то естественно повлияет. EP>>Но если у тебя stateful deleter — тебе его пришлось бы таскать вместе с указателем и без unique_ptr. То есть unique_ptr никакого нового оверхеда тут не добавляет. NB>дык о том и речь. он stateful, но в пределах вектора/класса/группы объектов. NB>допустим, в класс передается аллокатор, а в делетере хранится указатель на него. NB>естественно, таскать его с каждым элементом вектора -- лишний оверхед.
Да, в этом случае будет overhead. Но это не wrapping penalty, а penalty за лишние и неиспользуемые возможности(например move отдельного элемента вектора наружу). Для таких случаев можно использовать что-то типа boost::ptr_vector.
Точно также std::vector<int> даёт мини-оврхед в случаях фиксированного размера известного снаружи — тут подошёл бы std::unique_ptr<int[]>.
так каждый может. это не интересно.
EP>>>если stateful — то естественно повлияет. EP>>>Но если у тебя stateful deleter — тебе его пришлось бы таскать вместе с указателем и без unique_ptr. То есть unique_ptr никакого нового оверхеда тут не добавляет. NB>>дык о том и речь. он stateful, но в пределах вектора/класса/группы объектов. NB>>допустим, в класс передается аллокатор, а в делетере хранится указатель на него. NB>>естественно, таскать его с каждым элементом вектора -- лишний оверхед.
EP>Да, в этом случае будет overhead. Но это не wrapping penalty, а penalty за лишние и неиспользуемые возможности(например move отдельного элемента вектора наружу). Для таких случаев можно использовать что-то типа boost::ptr_vector.
все верно. только ptr_vector в стандарт не входит. свои поделки применяем...
просто просили продемонстрировать пример именно для unique_ptr.
Здравствуйте, night beast, Вы писали:
EP>>Да, в этом случае будет overhead. Но это не wrapping penalty, а penalty за лишние и неиспользуемые возможности(например move отдельного элемента вектора наружу). Для таких случаев можно использовать что-то типа boost::ptr_vector. NB>все верно. только ptr_vector в стандарт не входит. свои поделки применяем... NB>просто просили продемонстрировать пример именно для unique_ptr.
Я думаю изначально речь всё же шла про wrapping penalty. Случаи overkill'а можно продемонстрировать практически для чего угодно, например:
Здравствуйте, Evgeny.Panasyuk, Вы писали:
NB>>просто просили продемонстрировать пример именно для unique_ptr.
EP>Я думаю изначально речь всё же шла про wrapping penalty.
wrapping penalty можно получить если у нас не один, а два разных делетера.
или один делетер и один еще что-нибудь (или два что-нибудь)