많은 주장이있는 라이브러리를 작성하고 있습니다. assert가 켜져 있으면 라이브러리의 속도가 훨씬 느려지고 라이브러리의 전체적인 점이 빠르기 때문에 버그를 테스트하거나 진단 할 때만 assert가 의미가 있습니다. 나는 autoconf를 사용하고 있으며 사용자가이 문제에 대해 알도록 요구하고 어설 션을 비활성화하도록 구성하는 플래그를 전달하는 것이 표준 연습 인 것으로 보입니다. 이 경우 전문가 만이 적절한 버전의 라이브러리를 설치할 수 있습니다! 그게 내가해야할 일이고, 그렇다면 "전문가 사용자와 다른 프로그래머가 기대하는 것"이상의 그럴만한 이유가 있습니까?라이브러리 빌드 시스템에서 기본적으로 어설 션을 해제해야합니까?
편집 :Here's 다른 이유는 그렇게하는 놀라운 주어진하지만 당신이 릴리스 모드에서 기본적으로 NDEBUG를 정의하지해야한다는 논의의 예.
나는 이것을 지금 생각했습니다. NDEBUG를 정의 할 때의 문제는 정의되지 않은 동작으로 이어질 수 있다는 것입니다. Mine은 템플릿이 아닌 부분이있는 템플릿 라이브러리이므로 내 코드가 다른 사람들의 바이너리로 인라인됩니다. 비 인라인 코드를 컴파일 할 때 NDEBUG를 정의한 다음 클라이언트 코드가 NDEBUG없이 컴파일되면 헤더에 호환되지 않는 버전의 코드가 두 개 있습니다. 하나는 어설 션이고 다른 하나는없는 것입니다. 이것은 정의되지 않은 행동으로 이어지고 나 자신 전에 한 번 신비한 충돌로이 문제가 발생했습니다. 따라서 도서관에서 NDEBUG를 정의해야한다고 생각하지는 않습니다. 특정 컴퓨터에서 모든 것을 컴파일하는 사람 또는 빌드 시스템이 NDEBUG에 대해 결정해야합니다.
그러나 기본적으로 어설 션없이 라이브러리를 실행하기 위해 NDEBUG를 정의 할 필요는 없습니다. 이제 매크로 MYLIB_DEBUG 및 MYLIB_ASSERT가 있습니다. MYLIB_DEBUG가 정의되어 있지 않으면 MYLIB_ASSERT (X)는 아무것도하지 않습니다. MYLIB_DEBUG가 정의되면 MYLIB_ASSERT (X)는 assert (X)로 정의됩니다. 이렇게하면 NDEBUG를 사용하지 않고 어설 션을 선택합니다.
내 질문에 대한 대답은 기본적으로 라이브러리가 어설 션을 해제하는 것이 좋으며, 인터페이스에 어설 션이 포함 된 인라인 함수가있는 경우 NDEBUG를 정의하여 수행하지 않는 것입니다.
assert를 사용하면 라이브러리의 속도가 느려지고 꺼지게됩니다. 명확하게 문서화되었는지 확인하고 걱정하지 마세요.
어설 션으로 디버그하고 어설 션없이 최적화 된 릴리스의 두 가지 라이브러리 버전을 빌드해야합니다. 또한 릴리스 빌드에 * 값싼 주장을 남기는 것을 고려하십시오 (성능에 영향을주지 않으면 측정!) –
@dribeas 그게 좋은 생각입니다. (http://stackoverflow.com/questions/11695046/how-to-have-library- asserts-on-off-side-by-side), 적어도 유닉스 플랫폼에서는 비표준적인 것처럼 보인다. 특수 수정자를 추가하지 않은 라이브러리가 이름에 추가 된 것이 어설 션 또는 비 어설 션이어야하는 경우 여전히 문제가됩니다. 또한 사용자가 두 가지 버전을 묻지 않으면 기본적으로 어설 션 여부를 결정해야합니다. 나는 그 주장이 그들에게 요구하는 사람들에게만 있어야한다고 말하고 싶지만, 그것은 표준적인 실행에 반하는 것처럼 보이며, 나는 그것이 왜 그렇게 궁금합니다. –
@ DavidRodríguez-dribeas 아, 잠깐, 나는 당신이 "주장과 함께 디버그"라고 말하지 않았다. 이 질문은 디버그 빌드에 관한 것이 아닙니다. 그것은 소스에서 빌드하고 "make install"과 같은 일을 할 때 설치되는 기본 릴리즈 버전에 관한 것입니다. –