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

0

  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 CHayT, (Updated )

Комментарии (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», теперь такой хуйни писать не нужно.
    Ответить

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

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

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


    8