Здравствуйте, _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
Здравствуйте, k.o., Вы писали:
S>>>Да и любой смарт указатель это всё таки больше чем S>>>просто обёртка, не понятно с чем ты тут не согласен? J>>а какой оверхед несет unique_ptr ??
KO>deleter.
зависит от реализации. EBO все-же работает.
KO>На всякий случай, замечу, что я согласен с тем, что оверхед будет малозаметным или вовсе отсутствовать во многих (если не в большинстве) случаев.
Здравствуйте, _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);
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, k.o., Вы писали:
S>>>>Да и любой смарт указатель это всё таки больше чем S>>>>просто обёртка, не понятно с чем ты тут не согласен? J>>>а какой оверхед несет unique_ptr ??
KO>>deleter.
NB>зависит от реализации. EBO все-же работает.
KO>>На всякий случай, замечу, что я согласен с тем, что оверхед будет малозаметным или вовсе отсутствовать во многих (если не в большинстве) случаев.
Или надо было еще сказать, что иногда может понадобиться что-то более сложное чем default_deleter?
Здравствуйте, k.o., Вы писали:
KO>Или надо было еще сказать, что иногда может понадобиться что-то более сложное чем default_deleter?
а без разницы. сам себе unique_ptr не несет оверхеда. Даже с кастомным делетром. но если ты можешь показать код, который бы нес оверхед, было конечно интересно, но я в такое не верю.
Здравствуйте, 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>
Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради...
указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела.
_____________________
С уважением,
Stanislav V. Zudin
J>>и внезапно все накладные расходы исчезают...
SVZ>Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради... SVZ>указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела.
в unique_ptr хранится не указатель, а сам делетер. в часном случае (который привел k.o.) делетер — это указатель на функцию. Конечно в этом случае мы имеет 4 профуканных байта.
Я обернул этот делетер в ламбду. По сути лямбда — это функтор, структура с перекрытым оператом (). так эта лямбда не захватывает переменных(у неё пустой список []) , то у структуры нету полей. А раз так, то и в unique_ptr нечему хранится, никакого оверхеда нет.
J>>и внезапно все накладные расходы исчезают...
SVZ>Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради... SVZ>указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела.
В реализации для gcc хранится (только, конечно, не указатель а сам объект deleter'а). И в C++11 нельзя использовать decltype для лямбд. Можно, конечно, запилить, класс, который будет хранить deleter в статическом поле и избавиться от оверхеда, но, у этого решения есть, свои, очевидные, недостатки.
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, Вы писали:
SVZ>>Я не имею доступа к стандартной библиотеке С++'11, поэтому любопытства ради... SVZ>>указатель на deleter внутри std::unique_ptr хранится? Если да, то накладные расходы никуда не ушли, только читабельность кода просела. J>в unique_ptr хранится не указатель, а сам делетер. в часном случае (который привел k.o.) делетер — это указатель на функцию. Конечно в этом случае мы имеет 4 профуканных байта.
А я нигде не утверждал, что my_cool_custom_deleter это указатель на функцию.
J>Я обернул этот делетер в ламбду. По сути лямбда — это функтор, структура с перекрытым оператом (). так эта лямбда не захватывает переменных(у неё пустой список []) , то у структуры нету полей. А раз так, то и в unique_ptr нечему хранится, никакого оверхеда нет.
Только теперь, объект deleter'а, по-сути, гвоздями прибит к типу указателя.
Здравствуйте, 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 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, 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'а, по-сути, гвоздями прибит к типу указателя.
и? Примера демонстрирующего проблему я так понимаю ты не напишешь?
