Здравствуйте, _NN_, Вы писали:
_NN>Еще в древние времена С++98 вместо явного вызова delete используется деструктор , который вызывает delete внутри.
_NN>Новый C++ дает возможность отказаться и от 'new' за счет функций вида make_***. _NN>Преимущество нет проблем с утечками памяти при исключениях.
_NN>Т.е. эти конструкции нужны на более низком уровне, только чтобы написать обертки.
_NN>Согласны ли вы, что 'new' в обычном коде тоже устарел ?
Для тех кому пофиг на оверхед new/delete уже примерно лет 10 назад устарели.
А для тех кому не пофиг, не устарели и скорее всего никогда не устареют.
С++ он разный, такие дела.
Здравствуйте, _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' в обычном коде тоже устарел ?
да!
уже два года как устарели.
ЗЫ: на cplusplus куча бреда и ошибок, на него лучше не ссылаться.
Здравствуйте, skeptic, Вы писали:
S>Для тех кому пофиг на оверхед new/delete уже примерно лет 10 назад устарели.
синтаксический оверхед, да?
S>С++ он разный, такие дела.
и не все его могут выучить, ага
Здравствуйте, jazzer, Вы писали:
J>Конечно. Оно все устарело "еще в древние времена С++98" с приходом буста — все эти make_*** оттуда.
всетаки без variadic templates все эти make самому писать было сложно.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, skeptic, Вы писали:
S>>Для тех кому пофиг на оверхед new/delete уже примерно лет 10 назад устарели. A>синтаксический оверхед, да?
В эти "мэйки" можно чего угодно внутрь запихать.
Да и любой смарт указатель это всё таки больше чем
просто обёртка, не понятно с чем ты тут не согласен?
Что оверхед мал и с ним можно не считаться?
Так я с этим и не спорю — в моих задачах он мал,
но я вполне могу допустить существование ненулевого множества людей
для чьих задач он будет существенен.
Здравствуйте, skeptic, Вы писали:
S>Да и любой смарт указатель это всё таки больше чем S>просто обёртка, не понятно с чем ты тут не согласен?
а какой оверхед несет unique_ptr ??
Здравствуйте, skeptic, Вы писали:
S>>>Для тех кому пофиг на оверхед new/delete уже примерно лет 10 назад устарели. A>>синтаксический оверхед, да?
S>В эти "мэйки" можно чего угодно внутрь запихать. S>Да и любой смарт указатель это всё таки больше чем S>просто обёртка, не понятно с чем ты тут не согласен? S>Что оверхед мал и с ним можно не считаться? S>Так я с этим и не спорю — в моих задачах он мал, S>но я вполне могу допустить существование ненулевого множества людей S>для чьих задач он будет существенен.
ну-ка расскажи мне про оверхед unique_ptr, вдруг я что-то новое узнаю
Здравствуйте, _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 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, skeptic, Вы писали:
S>>Да и любой смарт указатель это всё таки больше чем S>>просто обёртка, не понятно с чем ты тут не согласен? J>а какой оверхед несет unique_ptr ??
deleter.
На всякий случай, замечу, что я согласен с тем, что оверхед будет малозаметным или вовсе отсутствовать во многих (если не в большинстве) случаев.
