В 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) настройки подобных проверок.
Один способ сам нашёл: написать в самом начале своей проги (важно, чтоб до (!) всех
#include
-ов)#define _DEBUG_HEAP_IMPL { }
.Основываясь на том, при желании можно создать новую конфигурацию: создать копию Debug и добавить в параметры командной строки
/D "_DEBUG_HEAP_IMPL={}"
.Так что теперь вопросы таковы:
есть ли у такого решения существенные недостатки?
может, всё же кто-то предложит что-то поэлегантнее?
а эту конфигурацию теперь можно сохранить не в параметрах проекта, а в параметрах среды? (если можно — как?)
Наверно, в вашем случае лучше воспольз-ся другим приемом: завести свой класс (пирамиду) с нужными настройками
А чем лучше-то?
Стоп, а что вообще имеется в виду под "завести свой класс"? Самому реализовать пирамиду, или как-то иначе?
отнаследоваться от std или завести членом своего класса — как будет удобней
обычно, при наследовании меньше кода писать
но в вашем случае, чтобы сделать интересующую настройку, как будет лучше — не думал