@rikimaru2013

Добрый день,

будет ли данный код работать по задумке, которую он имеет - хочу запретить создавать std::shared_ptr для типов у которых есть свой RefCounter

0

@hoggy

так и нужно запрещать не наследников,
а тех, у кого есть свой RefCounter.

для этого нужно четко обозначить признаки:
как определить, есть ли у класса RefCounter?
может быть у класса с RefCounter есть какой то особый метод?

0

@rikimaru2013

hoggy, так как я знаю, что вы знакомы с cocos2dx - проблема на лицо
Если хранить поле класса как умный указатель и случайно/неслучайно через некоторое время добавить его в Node ( addChild(ptr) )
то память будет уничтожена дважды, когда умрёт родительский Node и при очистки умного указателя - хочу защитить самого себя от самого себя!

Данный способ сработает? Если я когда-то добавлю классу признаки cocos2dx - везде где были "мои" умные указатели на этот класс начнётся дикая ругать

0

@hoggy

не понял смысла проблемы.

1

@Kastaneda

Очень похоже, что проблемы нет, а задача надуманная. С++ не простой язык, постоянно приходиться думать о том, что и как ты пишешь. Попытка дать программисту возможность не думать неоправданно усложняет все вокруг.
Имхо - я бы так не заморачивался, кто-то накосячил - сам дурак.

Добавлено через 4 минуты
а так можно свой make_shared, но это не дает 100% защиты, кто-то может создать shared_ptr без хелпера, но свой класс для shared_ptr также не дает 100% защиты, кто-то может создать shared_ptr и без него.

Добавлено через 4 минуты
ну и совсем дурной вариант - добавить в std специлизацию (через enable_if<has_ref_counter<T>>>), но за это по рукам бьют, в лучшем случае сразу.

1

@rikimaru2013

As always .....

Так можно написать про все использования static_assert

поиск std::shared_ptr по проекту подскажет

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

0

@Undisputed

Производные сущности не могут контролировать подобные аспекты
Если вам не нужно наследоваться от шаред пойнтера - просто не делайте этого

0

@rikimaru2013

Что? Вы хоть тему прочитайте((((( Пожалуйста))

0

MrGluck

Можно конечно, но стоит помнить про закон Мёрфи. И видимость что "всё хорошо" может оказаться хуже.

Раз уж начали обсуждать "плохие решения", то могу предложить ещё один плохой вариант - препроцессором shared_ptr менять на MySharedPtr.

1

Croessmah

А зачем Вам тогда умный указатель,
если там и так есть счетчик ссылок?

1

@rikimaru2013

Умные от утечки памяти, через месяц в дальнем дальнем файле определённой глубины кто-то решит наделить класс свойствами cocos2dx - всё будет работать, но падать в деструкторах при закрытии приложения без указания, где именно.
Накатал 100500 коммитов в отдельной ветке, подтянул мастер - падение в деструктор - а где не ясно. Ревью 100500 коммитов? Там всё норм. Ревью 100500 коммитов новых в мастере - и там всё норм "вроде бы", а вот вместе падение

0

@Undisputed

rikimaru2013,
У вас в примере идет наследование от шаред пойнтера которое вы как я понял хотите запретить в определенных условиях. Отвечая на вопрос "что" я говорю, что просто не наследуйтесь/не создавайте шаред там где это не нужно
Вот и все

0

MrGluck

Undisputed, он не хочет запретить наследование, он хочет запретить использование shared_ptr для классов, у которых уже есть счётчик. Наследование тут как пример решения данной проблемы.

1

@Undisputed

MrGluck,
Ну заголовок во всяком случае о наследовании...

ИМХО запретить делать глупости не получится, всегда можно написать код который будет делать что-то не хорошее
Нормальное решение в таком случае это не подпускать сомнительных разработчиков к проекту а не явные моменты хорошо документировать в том же readme или где нибудь еще.

Если слишком уж болит голова относительно одного конкретного случая, можно попробовать пересмотреть архитектуру что бы исключить наболевшую проблему.

0

@avgoor

rikimaru2013, Почему-то никто главного не сказал. Мешать разные системы автоматического управления памятью - плохая идея. shared_ptr тоже считает ссылки, просто счетчики разные в этом и проблема.
Не знаю, как там в cocos-е, но обычно если используется подсчет ссылок - деструктор должен быть protected (см. систему фасетов, например, а во всяких С# и прочих java просто нет delete, хоть реализация разная, смысл один - не дать удалить объект вручную). Тогда создать shared_ptr от класса с подсчетом ссылок просто не получится. Кроме того, при создании объекта обычно можно указать начальное значение счетчика ссылок и предотвратить его автоматическое удаление. Но лучше, все-таки, Использовать штатные средства движка (наверняка есть аналог shared_ptr в движке, в конце концов, как-то же объекты друг на друга ссылаются), тогда проблема исчезнет сама собой.

1