- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
namespace spine {
static SkeletonBatch* instance = nullptr;
void SkeletonBatch::setBufferSize (int vertexCount) {
if (instance) delete instance;
instance = new SkeletonBatch(vertexCount);
}
SkeletonBatch* SkeletonBatch::getInstance () {
if (!instance) instance = new SkeletonBatch(8192);
return instance;
}
SkeletonBatch::SkeletonBatch (int capacity) :
_capacity(capacity), _position(0)
{
_buffer = new V3F_C4B_T2F[capacity];
_firstCommand = new Command();
_command = _firstCommand;
Director::getInstance()->getScheduler()->scheduleUpdate(this, -1, false);
}
SkeletonBatch::~SkeletonBatch () {
Director::getInstance()->getScheduler()->unscheduleUpdate(this);
Command* command = _firstCommand;
while (command) {
Command* next = command->next;
delete command;
command = next;
}
delete [] _buffer;
}
https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-cocos2dx/3/src/spine/SkeletonBatch.cpp
Это просто шедевЕр! Течет как ссаные тряпки...
Follow us!
При условии что cocos собирается строго и только в динамическую библиотеку, а Spine является статической библиотекой и требуется как внутри имеджа cocos, так и внутри имеджа головного приложения, напрямую следует что SkeletonBatch - это совершенно не синглтон.
И течет, и не удаляется, и синглтон-не-синглтон. Такие дела, да...
Неужели все дело в том что при завершении setBufferSize(0) не вызывают? Ну это разве утечка.
> > ::getInstance()
мемоки лик нот детектед. синглтон детектед. "сач из дезайн" как говорят французы.
if (instance) delete instance;
удаляется.
А тем кто как несинглтон использует тем более никто не помешает удалить.
В общем я вижу единственную утечку в том что instance никто не удалит в момент завершения программы, из-за чего всякие детекторы утечек на нее сработают. Но в процессе выполнения никакой утечки нет.
Ну и да, утечка в момент завершения приложения ничем не грозит. Вообще ничем, особенно на ОС с общей памятью (вспоминаем историю развития iOS и некоторые мобильные операционки). :)
Ну и да, если эта iOS и некоторые мобильные операционки не умеют удалять память за приложением то их и за операционки считать сложно. А при падении приложения там тоже память течь будет?
Я что-то даже не верю, что последняя иос течет как ветренная шлюха, хотя дизаин у неё конечно как у гей шлюхи
я как-то в UIDatePicker течку нашел с помощью instruments, и запостил им баг
оказалось что еще человек 50 его нашли
class SkeletonBatch {
public:
...
protected:
SkeletonBatch (int capacity);
virtual ~SkeletonBatch ();
...
};
Виртуальный деструктор синглтона не участвующего в наследовании (наследоваться от него, кстати, нельзя конструктивно, так рантайм написан).
Особой мякотки добавляет опущенная здесь часть из которой видно что статического метода удаления у синглтона нет, то есть деструктор не вызовется никогда.
Впрочем в источнике "этого" - прекрасно все.
Подпиливаем сук всем, кто продолжает юзать старый инстанс?
п.с. или такую оптимизацию не придумали?
Дждесять лет ждём.
https://en.wikipedia.org/wiki/Escape_analysis
наверное здесь в каждой строчке sizeof(SkeletonBatch) меняется?