https://dlang.org/spec/expression.html#assert_expressions
The behavior of it can be set with a compiler switch to one of:
1. Immediately halting via execution of a special CPU instruction
2. Aborting the program
3. Calling the assert failure function in the corresponding C runtime library
4. Throwing the AssertError exception in the D runtime library
So there's no issue with parsing it. The compiler also understands the semantics of assert(), and so things like `assert(0)` can be recognized as being the end of the program.
That being said being slow or fast is kinda moot point if the program is not correct. So my advisor to leave always all asserts in. Offensive programming.
bool is_even(int* valPtr) {
assert(valPtr != nullptr);
return *valPtr % 2;
}
[0] https://dev.epicgames.com/documentation/en-us/unreal-engine/...
https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...
Abseil has the convention where instead of assert(), users call "CHECK" for checks that are guaranteed to happen at run time, or "DCHECK" for checks that will be compiled away when NDEBUG is defined.
https://github.com/abseil/abseil-cpp/blob/0093ac6cac892086a6...
https://github.com/abseil/abseil-cpp/blob/0093ac6cac892086a6...
`assert(vector.size() < 3)` is ridiculous to you?
But your meaning is clear. In an assert expression, don't call functions that might change the program/database state. Be as "const" as possible.
There are a few things like that, for example:
https://en.cppreference.com/w/c/numeric/math/isnan - isnan is an implementation defined macro.
https://en.cppreference.com/w/c/io/fgetc - `getc` may be implemented as a macro, but often it's a function.
htons(..) and related socket-utility names are also often macros, but I'm pretty sure there is not a std::htons(..) in the C++ standard, partly because 'htons' is not an attractive name. Since it's (sometimes) a macro don't qualify its namespace like ::htons(..).
A long time ago in the Microsoft C (and later C++) dev envs there were macros named "min" and "max", which I thought were terrible names for macros.
Yeah, this is still in windows.h unless you #define NOMINMAX
I remember having to guard against this in some inline code by surrounding the c++ calls with parenthesis, eg `(std::min)(a, b)`
I usually wrap Windows.h in a header followed by 100 #undefs to contain the disease.
https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...
In this case, the ability to see the actual values that triggered the assert is way more helpful.
It's not really something that can be fixed, other than moving away from the preprocessor and putting metaprogramming capabilities into the language itself (which C++ has been doing).
But I agree, fewer special tricks is better and that includes the preprocessor.
std::views::split(my_string, delimeter)
? spellcheck.cpp:1:19: error: unexpected character <U+201C>
1 | assert(spellcheck(“Friednly”));
| ^