4

I have some rather costly static_assert calls scattered throughout my code. While these are valuable, they are often superfulous and significantly contribute to compile time and memory usage.

Can I disable them?

Improve this question
7
  • 1
    Yes. By removing them. Commented Oct 30, 2014 at 1:52
  • @Rapptz How would I re-enable them? Commented Oct 30, 2014 at 1:54
  • 1
    Are you sure these static_assert calls are responsible for all that overhead? Commented Oct 30, 2014 at 1:54
  • @Brian not all of it, but many of them include non-trivial meta-functions that contribute substantially and aren't needed for all builds. Commented Oct 30, 2014 at 1:55
  • 1
    The only way to disable static_asserts is by removing them from the code which will be compiled, for example by using the preprocessor. They do not in any way contribute to the compiled code. Commented Oct 30, 2014 at 1:56

2 Answers 2

Reset to default
8

Wrap them in the standard NDEBUG macro.

#ifndef NDEBUG static_assert(...); #endif

That way for release builds you can disable them just like regular assert. Although I don't really see a purpose to this.

If you don't like wrapping up the calls in a macro, you can define a macro that does it for you:

#ifndef STATIC_ASSERT #ifndef NDEBUG #define STATIC_ASSERT(...) static_assert(__VA_ARGS__) #else #define STATIC_ASSERT(...) static_assert(true, "") #endif // NDEBUG #endif // STATIC_ASSERT

Usage is similar to a regular static_assert. Note that if your program defines a keyword and includes a standard library header then it is undefined behaviour to define a static_assert macro.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

I'm not particularly fond of this solution, but I guess it would do the job.
@quant Due to their compile-time aspect this is the only way to do it. Either that or removing them out right.
I really don't recommend coupling static checks (static_assert) with runtime-checks. If you want to remove one of them, it is quite possible you don't want to disable the others too.
@Deduplicator It could be replaced by whatever macro defined during the compilation process. I just used NDEBUG due to familiarity.
The replacement do { } while(0) won't work for static_asserts in namespace scope or in class bodies.
|
2

  1. You can either wrap them, each for itself, in its own #ifdef:

    #ifndef NO_STATIC_ASSERT static_assert(...); #endif

  2. Or, you can define your own STATIC_ASSERT:

    #ifndef NO_STATIC_ASSERT #define STATIC_ASSERT(...) /**/ #else #define STATIC_ASSERT(...) static_assert(__VA_ARGS__) #endif
    • In practice, #define static_assert(...) works too, though it is UB.
  3. Or, you can just manually remove them.

That way you can remove their influence on compilation-performance (they never had any influence on runtime-performance anyway).

Improve this answer

6 Comments

neat, I didn't think of that second one. Thanks :)
defining your own static_assert macro is undefined behaviour
@Deduplicator Defining keywords through the preprocessor is undefined behaviour iif the TU or header includes a standard library header which is likely. See here.
@Deduplicator Yes. The comments by Johannes seems to support my claims and I trust him. This is a pretty old and long winded debate with a lot of history though.
@Deduplicator It's in the latest draft here. I don't want to prolong this discussion though. Discuss this in the Lounge if you want.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.