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

    +51

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    class CHECKSTRUCTURE_API GroupOfDocs : public std::unordered_multimap<std::string, std::shared_ptr<Doc> > // структура, которую клиент заполняет и передает в качестве входных и выходных данных для process. Ключом является имя файла 
	{
	public:
#ifdef _DEBUG
		virtual ~GroupOfDocs() {};
#endif

    Запостил: laMer007, 13 Января 2015

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

    • ava laMer007 13.01.2015 16:46 # 0

      Идеи зачем тут #ifdef _DEBUG есть?
      Ответить

      • ava guest 13.01.2015 16:47 # 0

        точку останова ставить?
        Ответить

        • ava laMer007 13.01.2015 17:00 # 0

          Не угадал. От GroupOfDocs есть наследование. Это базовый класс.
          Ответить

          • ava laMer007 13.01.2015 17:07 # 0

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

      • ava 1024-- 13.01.2015 18:16 # +1

        А мне кажется, это кусок вот такого кода:
        #ifdef _DEBUG
  virtual ~GroupOfDocs() {
    // проверки на консистентность и прочая питушня
  }
#else
  virtual ~GroupOfDocs() {}
#endif

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

        • ava bormand 13.01.2015 19:17 # +4

          > Или же в дебаге что-то ругалось на какую-то странную фигню при удалении
          Годное предположение. При удалении через указатель на GroupOfDocs возникала утечка от недоудалённого объекта, у которого только половину полей почистили, и в дебаге об этом выводились какие-то сообщения... До автора не дошло, что этот виртуальный деструктор там должен находиться всегда а не только в дебаге... И со словами виртуальная питушня убивает мой пирфоманс он завернул это в #ifdef _DEBUG.
          Ответить

          • ava Soul_re@ver 14.01.2015 03:53 # 0

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

    • ava bormand 13.01.2015 19:50 # +1

      А ответ на загадку будет?
      Ответить

      • ava LispGovno 13.01.2015 22:22 # 0

        А что тут гадать?
        нарушение одр
        публичное наследование от того что должно быть в члене
        наследование от класа без виртуального деструктора

        ты о какой загадке вообще? тут же тривиальные ошибки
        Ответить

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