Кресты / Говнокод #20155 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 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
Это просто шедевЕр! Течет как ссаные тряпки...

Запостил: MarkusD MarkusD, (Updated )

Комментарии (25) RSS

  • Ну и еще, так, по мелочи.
    При условии что cocos собирается строго и только в динамическую библиотеку, а Spine является статической библиотекой и требуется как внутри имеджа cocos, так и внутри имеджа головного приложения, напрямую следует что SkeletonBatch - это совершенно не синглтон.
    И течет, и не удаляется, и синглтон-не-синглтон. Такие дела, да...
    Ответить
  • Я не вижу, где течет?
    Неужели все дело в том что при завершении setBufferSize(0) не вызывают? Ну это разве утечка.
    Ответить
    • Дело в том, что объект только создается и никогда не удаляется. Плюс, объект используется как синглтон, но инстанций его может быть много. Плюс, конечнож, метод setBufferSize.
      Ответить
      • > Дело в том, что объект только создается и никогда не удаляется.

        > > ::getInstance()

        мемоки лик нот детектед. синглтон детектед. "сач из дезайн" как говорят французы.
        Ответить
      • Ну вот же:
        if (instance) delete instance;
        удаляется.
        А тем кто как несинглтон использует тем более никто не помешает удалить.

        В общем я вижу единственную утечку в том что instance никто не удалит в момент завершения программы, из-за чего всякие детекторы утечек на нее сработают. Но в процессе выполнения никакой утечки нет.
        Ответить
        • В этом случае советую собрать, запустить и узреть. 🙂

          Ну и да, утечка в момент завершения приложения ничем не грозит. Вообще ничем, особенно на ОС с общей памятью (вспоминаем историю развития iOS и некоторые мобильные операционки). 🙂
          Ответить
          • Так она есть в процессе работы или нет? Может она еще в каком-то коде, который тут не показан?

            Ну и да, если эта iOS и некоторые мобильные операционки не умеют удалять память за приложением то их и за операционки считать сложно. А при падении приложения там тоже память течь будет?
            Ответить
            • На иос приложения не падают
              Я что-то даже не верю, что последняя иос течет как ветренная шлюха, хотя дизаин у неё конечно как у гей шлюхи
              Ответить
              • течет, да

                я как-то в UIDatePicker течку нашел с помощью instruments, и запостил им баг
                оказалось что еще человек 50 его нашли
                Ответить
            • Ну рассказывай, как обгонял, как подрезалсобирал, как запускал.
              Ответить
  • Оттуда же
    class SkeletonBatch {
    public:
    ...
    protected:
    SkeletonBatch (int capacity);
    virtual ~SkeletonBatch ();
    ...
    };
    Ответить
    • для синглтонов конструкторы с деструкторами прячут в protected/private, это норм.
      Ответить
      • Ок, без контекста возможно не ясно.
        Виртуальный деструктор синглтона не участвующего в наследовании (наследоваться от него, кстати, нельзя конструктивно, так рантайм написан).
        Особой мякотки добавляет опущенная здесь часть из которой видно что статического метода удаления у синглтона нет, то есть деструктор не вызовется никогда.
        Впрочем в источнике "этого" - прекрасно все.
        Ответить
        • некоторые сдк по умолчанию создают класс с explicit конструктором и virtual деструктором, да и в целом пофиг на это.
          Ответить
  • > if (instance) delete instance;
    Подпиливаем сук всем, кто продолжает юзать старый инстанс?
    Ответить
    • можно понадеяться что все пары delete/new будут выкидывать аллокацию/деаллокацию памяти.

      п.с. или такую оптимизацию не придумали?
      Ответить
        • так тут то намного проще. Условно, зачем делать деаллокацию памяти и последующую аллокацию такого же размера?
          Ответить
            • if (instance) delete instance;
              instance = new SkeletonBatch(vertexCount);

              наверное здесь в каждой строчке sizeof(SkeletonBatch) меняется?
              Ответить
              • А откуда ты знаешь, что раньше там лежал именно SkeletonBatch?
                Ответить
              • Удаляется буфер с одним vertexCount и создается с другим, очевидно он будет (в общем случае) другого размера.
                Ответить

Добавить комментарий

Переведи на "PHP", guest!

    А не использовать ли нам bbcode?


    8