Windows CRT и утверждает создание отчетов (аварийное прекращение работы, повторите, проигнорируйте),
Это грубо, но если у Вас, как гарантируют, будет по крайней мере один, Вы могли бы сделать:
SELECT ...
...
WHERE tag IN( @tag1, ISNULL( @tag2, @tag1 ), ISNULL( @tag3, @tag1 ), etc. )
Наличие В ('tag1', 'tag2', 'tag1', 'tag1', 'tag1') будет легко оптимизировано далеко SQL Server. Плюс, Вы добираетесь, прямой индекс ищет
5 ответов
Это работает (по крайней мере, для меня, по сравнению с 2008 годом): (По сути, вернуть TRUE из подключенной функции)
int __cdecl CrtDbgHook(int nReportType, char* szMsg, int* pnRet)
{
return TRUE;//Return true - Abort,Retry,Ignore dialog will *not* be displayed
return FALSE;//Return false - Abort,Retry,Ignore dialog *will be displayed*
}
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
_CrtSetReportHook2(_CRT_RPTHOOK_INSTALL, CrtDbgHook);
assert(false);
getch();
return 1;
}
Вы также можете написать свое собственное поведение, подобное утверждению (обратите внимание, что это покажет диалоговое окно «Break, Continue»):
#define MYASSERT(x) { if(!(x)) {DbgRaiseAssertionFailure();} }
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
MYASSERT(false);
getch();
return 1;
}
Надеюсь, что это поможет!
Почему это утверждение? assert (false) выглядит так, как будто "никогда не должно происходить", код был выполнен в CRT. Я бы испугался на твоем месте. Всегда ли на одной линии? Есть какие-нибудь комментарии по этому поводу?
РЕДАКТИРОВАТЬ: Я имею в виду: assert происходит в коде CRT, потому что есть некоторые предположения, что он проверяет, что вы не встречаетесь (возможно, вам удалось подключиться к смешанной среде выполнения, или вы создали управляемую сборку C ++ и забыли вручную инициализировать CRT, или вы пытаетесь вызвать LoadLibrary из DllMain или что-то еще, что никогда не должно происходить).
Итак, прежде чем выяснять, как подавлять утверждения, выясните, почему именно оно вообще выполняет утверждения. В противном случае вы, вероятно, позже столкнетесь с кажущимися несвязанными проблемами и получите много удовольствия, пытаясь их отладить. (из вашего вопроса неясно, знаете ли вы, о чем эти утверждения)
Подобный код
if(somebadcondition)
{
assert(false);
// recovery code
}
буквально означает «эта ветвь кода никогда не должна выполняться».
Ответ Ляо проведет вас почти полностью, но я хотел бы предложить вам добавить еще одну вещь в свой отладочный крючок:
int __cdecl StraightToDebugger(int, char*, int*)
{
_CrtDbgBreak(); // breaks into debugger
return TRUE; // handled -- don't process further.
}
В противном случае ваши утверждения просто исчезнут, и процесс завершится.
Проблема с этим подходом состоит в том, что - по крайней мере, для моей домашней установки VC Express - отладчик выдает большое сообщение «program.exe инициировал точку останова» вместо обычного сообщения о сбое утверждения, поэтому он не может быть большим улучшением.
Я не уверен, хотите ли вы, чтобы поведение быть для любого assert , или если вы просто пытаетесь использовать assert (false) специально как шаблон общего назначения для безоговорочного взлома отладчика на заданной строке. Если это первое, см. Ответы Ляо и Ким. Если это последнее, то вам действительно стоит использовать вместо нее внутреннюю функцию __ debugbreak .
Почему бы не использовать DebugBreak Function ?
Или даже использовать код операции?
#ifdef _X86_
#define BreakPoint() _asm { int 3h }
#else
#define BreakPoint() DebugBreak()
#endif
До Visual C ++ 2005, инструкция ,
__ asm int 3не приводил к созданию собственного кода при компиляции с / clr; компилятор перевел инструкция для прерывания CLR инструкция. Начиная с Visual C ++ 2005, __asm int 3 теперь приводит к генерация собственного кода для функция. Если вы хотите, чтобы функция вызвать точку останова в вашем коде и если вы хотите, чтобы эта функция была скомпилирована MSIL, используйте __debugbreak.