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

    +7

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    namespace engine { namespace ui { class Console; } }

class Dummy
{
   engine::ui::Console * _ptr;
};

    Решение проблемы с перекрёстными #include, когда классы должны хранить указатели друг на друга. Простое объявление class engine::ui::Console; не работает.
    Не в первый раз сталкиваюсь с этой проблемой из-за примитивной системы импорта.

    Запостил: an0nym, 20 Июля 2013

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

    • ava Treulos 20.07.2013 23:22 # −1

      Разделять классы на .hpp и .cpp - не умеете?
      Ответить

      • ava an0nym 21.07.2013 00:32 # −1

        Причём здесь это?
        Ответить

        • ava Treulos 21.07.2013 00:55 # −1

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

          //тут было много текста.
          Ответить

          • ava defecate-plusplus 21.07.2013 00:59 # +1

            никогда такого не видел?
            struct a;
struct b { a * ptr; };
struct a { b * ptr; };
            как ему тут поможет то, о чем ты говоришь?
            Ответить

            • ava Treulos 21.07.2013 01:02 # −2

              Да я и говорю, что по ночам плохо соображаю. Об этом подумал в посл. момент.
              Но вообще-то, если приходится такое городить - то это явно проблемы архитектуры приложения.
              Ответить

          • ava roman-kashitsyn 21.07.2013 23:17 # +5

            форварды - чудесная вещь. От них не надо уходить. Наоборот, чем чаще получается заменить полный инклюд на форвард, тем лучше. Полное определение типа нужно, только если зависимый класс содержит поле типа, наследуется от этого типа или вызывает его методы в хедере. Без форварда невозможен pimpl.
            Трудно представить, сколько времени компилился бы clang, если бы там все форварды заменили на инклюды...
            Ответить

    • ava defecate-plusplus 20.07.2013 23:44 # 0

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

      • ava an0nym 21.07.2013 00:38 # −2

        Указателями связаны графическая консоль и интерпретатор, которому нужно посылать ввод и получать ответ.
        Стиль именования из Qt почерпнул, так ентерпрайзнее выглядит.
        Ответить

        • ava defecate-plusplus 21.07.2013 00:47 # 0

          qt и ынтерпрайз - поделил на 0

          кроме forward declaration есть еще минимум 3 способа увязать классы
          Ответить

          • ava Xom94ok 21.07.2013 10:04 # +5

            >>qt и ынтерпрайз - поделил на 0
            Словил SIGFPE и проигнорировал. У Qt логичный и обоснованный стиль оформления кода, в его сорцах чуточку приятнее копаться, чем в каком-нибудь boost.

            >>еще минимум 3 способа
            А какой же третий?
            Ответить

            • ava Treulos 21.07.2013 18:04 # −3

              Когда-то давно мне было лень разделять классы на 2 файла и чтобы иметь сделать такое мне пришлось сделать первый класс шаблонным и при первой возможности затайпдефить.лол.
              Ответить

            • ava defecate-plusplus 21.07.2013 18:15 # +2

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

              • ava Xom94ok 21.07.2013 19:04 # 0

                Как минимум с версии 4.7 Qt можно сконфигурировать, указав опцию "-qtnamespace <namespace>", оборачивающую код библиотек в указанное пространство имен.
                >>ебланскими Q-префиксами
                OK, дальше явно спорить бессмысленно.
                Ответить

                • ava defecate-plusplus 21.07.2013 20:18 # 0

                  т.е. предлагается опционально обернуть _всю_ немаленькую библиотеку qt в _один_ неймспейс, сохранив раздражающие префиксы
                  ЕМНИП у moc (кстати, очередное гениальное творение - вставить лишнюю сущность в тулчейн, ибо ниасилили - такой типичный ентерпрайз бгг) были непреодолимые проблемы, если пользовательский класс с Q_OBJECT находился в "неправильном" неймспейсе
                  Ответить

            • ava defecate-plusplus 21.07.2013 18:17 # +4

              > А какой же третий?
              1. интерфейс
              2. шаблон
              3. коллбек
              Ответить

        • ava roman-kashitsyn 21.07.2013 11:55 # +5

          > Указателями связаны графическая консоль и интерпретатор

          На кой ляд? Зачем привязывать модель к представлению? Зачем интерпретатору знать о консоли? А если я к вебу захочу его прикрутить?
          class repl
{
    std::isream _in;
    std::osream _out;
    interpreter & _interpr;
public:
    /* ... */
    void run()
    {
        std::string input;
        while (!_interpr.done()) {
            _in >> input;
            sdt::string resp = _interpr.eval(input);
            _out << resp << sdt::endl;
        }
    }
};
          Ответить

    • ava Stertor 25.07.2013 08:33 # 0

      namespace xui
      Ответить

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