C++26: A User-Friednly assert() macro
sandordargo.com

・

48 points

・

jandeboevrie

・

3 days ago

35 comments

MontagFTB ・ 4 hours ago

Putting code with side effects into an assert is asking for trouble. Compile with NDEBUG set and the effects mysteriously disappear! Anything beyond an equality expression or straight boolean should be avoided.

  • usrnm ・ 3 hours ago

    I once spent several days debugging that same mistake. Stuff worked perfectly in tests but broke misteriously in production builds. Couldn't stop laughing for a few minutes when I finally figured it out.

  • maccard ・ 2 hours ago

    Indeed.

       bool is_even(int* valPtr) {
      assert(valPtr != nullptr);
      return *valPtr % 2;
    }
    Does not do what you think it does with nullptr. A major game engine [0] has a toggle to enable asserts in shipping builds, mostly for this reason

    [0] https://dev.epicgames.com/documentation/en-us/unreal-engine/...

    • mhh__ ・ 38 minutes ago

      This is a very "Dr Dr it hurts when I do this" "Don't do that" one it must be said.

    • dccsillag ・ an hour ago

      I'm sorry, but what exactly is the problem with the code? I've been staring at it for quite a while now and still don't see what is counterintuitive about it.

      • IshKebab ・ an hour ago

        There's nothing wrong with it. It does exactly what you think it does when passed null.

  • samiv ・ an hour ago

    That's why you define your own assert macro and keep in on unconditionally. Your programs will be better for it.

    • jandrewrogers ・ an hour ago

      An assertion can be arbitrarily expensive to evaluate. This may be worth the cost in a debug build but not in a release build. If all of assertions are cheap, they likely are not checking nearly as much as they could or should.

      • samiv ・ an hour ago

        Possibly but I've never seen it in practice that some assert evaluation would be the first thing to optimize. Anyway should that happen then consider removing just that assert.

        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.

  • nyc_pizzadev ・ 4 hours ago

    This is just a symptom of a bad assert() implementation, which funny enough is the standard. If you properly (void) it out, side effects are maintained.

    https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...

  • jmalicki ・ 3 hours ago

    Side effects are bad of course, but anything beyond a straight boolean or equality is bad?

    `assert(vector.size() < 3)` is ridiculous to you?

  • nealabq ・ 3 hours ago

    I don't mean to be that guy, but for "functional" programmers a print statement has "side effects".

    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.

    • toxik ・ 2 hours ago

      Not just for functional programmers. Prints and other I/O operations absolutely are side effects. That's not running counter to the point being made. Print in an assert and NDEBUG takes away that behavior.

omoikane ・ 4 hours ago

> (assert) doesn't follow the usual SCREAMING_SNAKE_CASE convention we associate with macros

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.

  • nealabq ・ 3 hours ago

    In C++ you should probably #include <cstdio> instead of <stdio.h> unless you have a good reason. And especially avoid #including both. <cstdio> provides the function std::getc(..) while <stdio.h> usually provides getc(..) as a macro.

    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.

    • adzm ・ an hour ago

      > 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)`

      • nananana9 ・ 39 minutes ago

        Yep. There's tons of others as as well. 16-bit x86 enjoyers will be happy to know there are `near` and `far` macros whose primary purpose in 2026 is to break my projection matrices. And of course every Win32 function that takes strings has a macro that resolves it to either the UTF-16 or ASCII variant, so your custom CreateWindow is now a CreateWindowA, tough luck buddy.

        I usually wrap Windows.h in a header followed by 100 #undefs to contain the disease.

nyc_pizzadev ・ 5 hours ago

The nice thing about assert() is you can just define your own:

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.

adzm ・ 44 minutes ago

One of my favorite things from ATL/WTL was the _ASSERT_E macro which additionally converts the source expression to text for a better message to be logged

grokcodec ・ 3 hours ago

Friedns shouldn't let Freidns post on HN without running spell check

amelius ・ 3 hours ago

Shouldn't the preprocessor be fixed, if it trips that easily on common C++ constructs?

  • marginalia_nu ・ 3 hours ago

    Preprocessor is just doing text transformations on the sources.

    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).

    • amelius ・ an hour ago

      I mean, you could extend it such that a simple comma has no special meaning.

      But I agree, fewer special tricks is better and that includes the preprocessor.

  • tom_ ・ 3 hours ago

    I'm sure the standardization committee are always looking for fresh ideas!

semiinfinitely ・ 3 hours ago

"C++47: Finally, a Standard Way to Split a String by Delimiter"

  • porise ・ 2 hours ago

    I'm still waiting for C++ to support Unicode properly.

  • einpoklum ・ 35 minutes ago

    A standard way to split a string? Well, what's wrong with:

        std::views::split(my_string, delimeter)

?
    • nananana9 ・ 29 minutes ago

      Template bloat, terrible compile errors, terrible debug build performance, 1 second of extra compile time per cpp file when you include ranges, and you can't step through it in a debugger.

throwpoaster ・ 3 hours ago

assert(spellcheck(“Friednly”));

  • nananana9 ・ 26 minutes ago 

      spellcheck.cpp:1:19: error: unexpected character <U+201C>
      1 | assert(spellcheck(“Friednly”));
        |                   ^