Блог пользователя IlyaCk

Автор IlyaCk, 11 лет назад, По-русски

В Visual C++ (как в полной, так и в Express-версиях) есть возможность переключаться между стандартной Debug-конфигурацией и стандартной Release-конфигурацией. Один и тот же код при запуске в этих разных конфигурациях ведёт себя по-разному во всяких мелких вопросах, главным образом — проверках. В общем и целом, всё неплохо продумано, очень помогает и отловить ошибки во время отладки (Debug), и получить эффективный окончательный код (Release).

Но иногда эти проверки замедляют выполнение программы не в 2---10 раз (что почти всегда терпимо), а асимптотически. Например, каждая операция с пирамидой (priority_queue), которая вообще-то требует действий, начинает полностью проверять свойство "каждый отец больше-равен каждого из своих сыновей" по всей пирамиде, что естественно требует Ω(size).

Я далёк от мысли считать, будто эта проверка основного свойства пирамиды всегда лишняя и Microsoft дураки что включили её в библиотеку. Она бывает полезна — главным образом, когда сам не заметил, что перегрузил где-то operator < так, что он не оказался одновременно полным, антисимметричным и транзитивным, и вследствие этого нарушились нужные свойства пирамиды.

И всё равно порой возникает ситуация, когда я абсолютно уверен в правильности перегрузки operator < и в правильности работы именно пирамиды, но не уверен в других вещах. Как следствие — хочется подольше потестировать всё это в Debug-конфигурации, но не хочется ждать в сотни или тысячи раз дольше ради проверок пирамиды, в которой я и так уверен.

Можно ли штатными средствами отключать одну лишь только проверку основного свойства пирамиды? Я примерно представляю, как этого добиться, тупо нагло меняя текст функции void _Debug_heap(_RanIt _First, _RanIt _Last, _Pr _Pred) библиотеки alrorithm, но можно ли обойтись без такого неприличного действия как самому тупо нагло менять текст функции из стандартной библиотеки?

В принципе интересуют и другие аналогичные вопросы более тонкой (чем Debug/Release) настройки подобных проверок.

  • Проголосовать: нравится
  • +24
  • Проголосовать: не нравится

»
11 лет назад, # |
Rev. 2   Проголосовать: нравится +6 Проголосовать: не нравится

Один способ сам нашёл: написать в самом начале своей проги (важно, чтоб до (!) всех #include-ов) #define _DEBUG_HEAP_IMPL { }.

Основываясь на том, при желании можно создать новую конфигурацию: создать копию Debug и добавить в параметры командной строки /D "_DEBUG_HEAP_IMPL={}".

Так что теперь вопросы таковы:

  1. есть ли у такого решения существенные недостатки?

  2. может, всё же кто-то предложит что-то поэлегантнее?

  3. а эту конфигурацию теперь можно сохранить не в параметрах проекта, а в параметрах среды? (если можно — как?)

  • »
    »
    11 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    Наверно, в вашем случае лучше воспольз-ся другим приемом: завести свой класс (пирамиду) с нужными настройками

    • »
      »
      »
      11 лет назад, # ^ |
      Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

      А чем лучше-то?

      Стоп, а что вообще имеется в виду под "завести свой класс"? Самому реализовать пирамиду, или как-то иначе?

      • »
        »
        »
        »
        11 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится

        отнаследоваться от std или завести членом своего класса — как будет удобней

        обычно, при наследовании меньше кода писать

        но в вашем случае, чтобы сделать интересующую настройку, как будет лучше — не думал