LINUX.ORG.RU

Разрушение объектов, на которые указывают статические указатели.


0

1

Есть класс Application. Изначально он был синглтоном, но теперь я думаю, что плюсов этого паттерна здесь нет, т.к. объект существует всегда, а обращаться к нему через статический метод не очень удобно.
Решил сделать класс статическим. Внутри класса есть указатель AbstractScene. В main.cpp я делаю примерно следующее, Application::setScene(new ConcreteScene()).
Однако я беспокоюсь про разрушение этой ConcreteScene. Проверил - деструктор не вызывается. Стоит ли в этом случае использовать например auto_ptr?

создаётся этот ConcreteScene в main, там и разрушай, хотя если нужно, чтобы он разрушился после разрушения Application, то в его деструкторе делай, правда это очень неправильно (по правилу «удаляй там, где создал»). Можно сделать Application::clearScene(); delete scene; в main, если Application нужно знать, когда ты захочешь разрушить ConcreteScene.

Лучше всего передать такое

shared_ptr<ConcreteScene> scene(new ConcreteScene());
Application::setScene(scene);
, тогда переданный ConcreteScene удалится после того, как завершится Application(или в ней заменится сцена на новую) и main закончится или в ней очистится или переинициализируется этот указатель.

jeuta ★★★★
()

Нафиг освобождать ресурсы. которые используются на протяжении всего времени работы программы?

anonymous
()
~$ cat 1.cpp
#include <cstdio>
using namespace std;

struct AbstractScene {};
struct Scene : public AbstractScene {
    ~Scene(){printf("~Scene\n");}
    static Scene& instance() {static Scene r; return r;}
};

int main() {
    Scene::instance();
}

~$ g++ 1.cpp
~$ ./a.out 
~Scene

для new - ты обязан сам вызывать delete

wota ★★
()

Проверил - деструктор не вызывается

Деструктор чего? Я так понял у тебя статический класс, а не объект.

плюсов этого паттерна здесь нет

Плюс в вызове деструктора, в т.ч. при исключении, что может быть важно, если нужно перед смертью что-то сделать. Да и вообще это более кошерно.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Я так понял у тебя статический класс, а не объект.

Фига, народ, пошёл С++ расширять!

Begemoth ★★★★★
()
Ответ на: комментарий от jeuta

valgrind'ы если будешь пускать, то лучше заранее озаботиться

Заниматься фигнёй из-за того, что какая-то утилита считает себя умнее автора?

anonymous
()

Да. Только канонично правильнее будет заюзать unique_ptr

nanoolinux ★★★★
()
Ответ на: комментарий от no-such-file

У меня так:

class Application {
private:
     static Window          m_window;
     static AbstractScene*  m_scene;

public:
     static void            setScene(AbstractScene* scene);
     static AbstractScene*  scene();

     static void            exec();
     ...
     ...
};
В main.cpp примерно так:
int main() {
        Application::setScene(new BlurTestScene());
        Application::window()->setSize(800, 600);
        return Application::exec();
}
Нужно чтобы вызывался деструктор на BlurTestScene. Сделал это с помощью auto_ptr. Можно было бы использовать unique_ptr, но пока С++11 в проекте пока не использую.

sol_linux ★★
() автор топика
Последнее исправление: sol_linux (всего исправлений: 1)
Ответ на: комментарий от anonymous

слава роботам!

ТСу: с тем же успехом можно было в конце main удалить этот твой ConcreteScene

jeuta ★★★★
()
Ответ на: комментарий от Boy_from_Jungle

а что будет, когда ты из нескольких потоков несколько раз сделаешь new BlurTestScene? очевидно у ТС это место дергается один раз из main - и тут без разницы, как создается сцена, ну и gcc прикрывает такие места, но это конечно лично его инициатива, при желании можно и руками прикрыть

wota ★★
()
Ответ на: комментарий от wota

смотри new BlurTestScene я там не вижу, но сейчас не в этом вопрос, дело в том, что только стандарт С++11 гарантирует, что такое определение будет корректно проинициализировано если его попытаются сделать из нескольких потоков.

Boy_from_Jungle ★★★★
()
Ответ на: комментарий от Boy_from_Jungle

new BlurTestScene я там не вижу

Разрушение объектов, на которые указывают статические указатели. (комментарий)

дело в том, что только стандарт С++11 гарантирует

если говорить про thread-safety - это частное дело каждой реализации и даже каждой функции, может быть, а может и нет

wota ★★
()
Ответ на: комментарий от Boy_from_Jungle

я имел ввиду этот коммент, а не тот который ты мне подсовываешь.

в том, который я тебе «подсовываю» просто другое название класса, задача решается одна и та же

Но дело в другом я тебе уже это разъяснил

ты решил «ляпнуть» о чем-то, что прочитал раньше, молодец, конечно, но иногда лучше промолчать

wota ★★
()
Ответ на: комментарий от wota

в том, который я тебе «подсовываю» просто другое название класса, задача решается одна и та же

угу, за такое нужно руки рубить

ты решил «ляпнуть» о чем-то, что прочитал раньше, молодец, конечно, но иногда лучше промолчать

не вижу смысла молчать, т.к. код плохо пахнет

Boy_from_Jungle ★★★★
()

Используйте

#define iApp MyApplicationClass::instance()
для быстрого написания кода и верните синглтон.

trex6 ★★★★★
()
Ответ на: комментарий от trex6

это высер в высшей степени ...

сначала задрот боящийся глобальных переменных создает синглтон теже яйца только в профиль ... а потом еще и макрос добавляет ... срочно на трепанацию черепа нахуй

anonymous
()
Ответ на: комментарий от anonymous

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

trex6 ★★★★★
()
Ответ на: комментарий от trex6

Я готов даже оплатить вам первое занятие, раз уж мы оказались с вами на одном форуме.

Хорошо, с вас 500 баксов, сударь.

anonymous
()
Ответ на: комментарий от anonymous

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

trex6 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.