1. C++ / Говнокод #5536

    +163

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    Engine::GetSingleton()->SetCallbacks(
    	new myname::Method<void(void),Application>(&Application::Render, boost::weak_ptr<Application>(application)),
    	new myname::Method<void(void),Application>(&Application::Update, boost::weak_ptr<Application>(application)),
    	0,
    	0,
    	new myname::Method<void(void),Application>(&Application::Init, boost::weak_ptr<Application>(application)),
    	new myname::Method<void(void),Application>(&Application::Cleanup, boost::weak_ptr<Application>(application))
    );

    Особая шаблонная магия + ООП мозга.

    Запостил: CHayT, 05 Февраля 2011

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

    • ненавижу синглтоны!!
      а шаблончики в принципе нормальные, только не понятно зачем они...
      Ответить
      • Нафига там явно указывать параметры шаблонов?
        Ответить
        • Затем, что это создание объекта шаблонного класса, а не вызов шаблонной функции.
          Ответить
          • Для этого существуют шаблонные фабрики.
            Ответить
            • Так для этого они должны существовать. Здесь таких не видно.
              Ответить
      • А чем именно Вас не устраивают синглтоны?
        Ответить
        • неправильным их использованием = )
          Ответить
        • и вызовом GetInstance()
          а еще для того чтоб включить хидер с синглтоном, нужно включить все хидеры от которых он зависит, хотя в большинстве случаев человеку нужна какая нибудь захудалая функция, которая принимает инт и возвращает инт и сама по себе не имеет зависимостей...
          сейчас пытаюсь заменить синглтоны на неймспейсы или структуры со статическими методами (оно немного удобнее), а все данные описывать в С++ файле, скрывая их от внешних глаз... получается лучше, но как-то не очень удобно, а у новичков от вида этого вообще батхерт случается, но избавление от лишних зависимостей и ускорение компиляции этого стоят...
          Ответить
          • > структуры со статическими методами (оно немного удобнее)
            Прикольно, только порядок инициализации статических членов не определён. Собираем приложение без ошибок и получаем вылет ещё до входа в main. Или непредсказуемое поведение.
            Ответить
            • P.S. Прочитал "статическими полями" а не "статическими методами". Тогда ладно.
              Ответить
          • GetInstance() - всегда прячу в обёртку со статическими методами и не каких проблем. :)

            Скорость компиляции - это конечно проблема, но это проблема видна ещё больше, если использовать шаблоны, так что в случае синглтонов это не проблема.
            Ответить
            • данные синглтона могут потянуть за собой кучу шаблонов при чем во все файлы в которые включен этот синглтон, в не зависимости что реально используется в этом файле...
              Ответить
          • Вы их просто не умеете готовить Он вам возможно не нужен (он действительно не так уж часто нужен). А если нужен -- узнаете об этом, наступив на грабли, для обхода которых и придуман синглтон.
            Ответить
      • Судя по всему, это очередная извращённая реализация чего-то bind-оподобного...
        Ответить
        • Да. С наследованием от абстрактного класса ещё.
          Ответить
          • Что ж мешало сделать что-нибудь вроде (навскидку) вот такого? Писать всё же чуть меньше (после небольших подготовительных работ).

            class FunctorBase
            {
            public:
            virtual operator() = 0;
            };

            template <typename T>
            class FunctorTyped : public FunctorBase
            {
            T f_;
            public:
            Functor(const T& f): f_(f) {}
            virtual operator() { f_(); }
            };

            template <typename T>
            inline FunctorTyped<T> functor(const T& f)
            {
            return FunctorTyped<T>(f);
            }

            ...

            Engine::GetSingleton()->SetCallbacks(
            functor(boost::bind(&Application::Render , application)),
            functor(boost::bind(&Application::Update , application)),
            0,
            0,
            functor(boost::bind(&Application::Init, application)),
            functor(boost::bind(&Application::Cleanu p, application))
            );
            Ответить
            • Можно просто убрать явное взятие слабого указателя:
              Engine::GetSingleton()->SetCallbacks(
              			new snaut::Method<Application,void(void)>(&Application::Render, application),
              			new snaut::Method<Application,void(void)>(&Application::Update, application),
              			0,
              			0,
              			new snaut::Method<Application,void(void)>(&Application::Init, application),
              			new snaut::Method<Application,void(void)>(&Application::Cleanup, application)
              		);
              Ответить
              • От явной типизации шаблона так и не избавились. Сделайте шаблонную функцию, которая вызывает тот же new - ей параметры уже можно будет не задавать.
                Ответить
            • очень непонятно зачем функтор от кого-то наследовать... лучше функцию где он применяется сделать шаблоном...
              Ответить
              • Предположим, что у нас есть некий класс, в объектах которого содержится не по одному колбеку на каждое событие, а по целому списку колбеков. Максимальная гибкость обеспечивается в том случае, если к списку можно добавлять что угодно, лишь бы с правильным интерфейсом. Например, boost::bind(&A::method1, a, _1, 50), boost::bind(&B:method2, b, c, d, _1) и т.п. Нетрудно догадаться, что все эти бинды вернут значения разных типов, поэтому и функторы будут специализироваться разными типами. Самый простой способ сложить их все в один контейнер - отнаследовать их все от чего-то нешаблонного.
                Ответить
                • Так и было. Велосипедный делегат был изобретён именно для очереди событий от произвольных объектов, колбэки уже потом попробовал с его помощью сделать. Говнисто получилось, не правда ли?
                  Ответить
                  • Бывает и хуже. Главное, чтобы этот путь в итоге довёл куда надо.
                    Ответить
                • в принципе да... борьба за универсальность требует жертв в производительности...
                  Ответить
            • можно заметить что все функции имеют одинаковое объявление, поэтому возиться с чем-то бинд подобным нет смысла...
              Ответить
              • Одинаковая сигнатура, безусловно, всё упрощает, но это же только частный случай. А для общего мне уже не раз и не два приходилось использовать схемы, похожие на ту, что выше. С той лишь разницей, что у нас конкретно для колбеков уже давно написана специальная подсистема, в которой можно вешать что угодно куда нужно без лишних напрягов и геморроя с временем жизни (колбек и то, на что он вешается, могут уничтожаться в любом порядке). Работает как часы.
                Ответить
    • - Да, сестра рассказала, как Вас покормила, и, судя по всему, пища Вам впрок не пошла.
      Ответить
    • То ли дело «C++20»: завезли «CTAD», теперь такой хуйни писать не нужно.
      Ответить

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