Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sandordargo.com

Post reply on HN
Print view View original

31–40 of 89 posts

Re: C++26: A User-Friednly assert() macro

#31

Post by nananana9 »

adzm wrote: post #27
nealabq wrote: post #16

Earlier quoted context omitted.

In C++ you should probably #include instead of unless you have a good reason. And especially avoid #including both. provides the function std::getc(..) while 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…

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

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.

Re: C++26: A User-Friednly assert() macro

#32

Post by mhh__ »

maccard wrote: post #21
MontagFTB wrote: post #5

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.

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

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

Re: C++26: A User-Friednly assert() macro

#34

Post by [deleted] »

amelius wrote: post #23
marginalia_nu wrote: post #15

Earlier quoted context omitted.

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

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.

[deleted]

Re: C++26: A User-Friednly assert() macro

#35

Post by nananana9 »

einpoklum wrote: post #33
semiinfinitely wrote: post #12

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

A standard way to split a string? Well, what's wrong with: std::views::split(my_string, delimeter) ?

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.

Re: C++26: A User-Friednly assert() macro

#37

Post by nmilo »

omoikane wrote: post #8
nyc_pizzadev wrote: post #6

Earlier quoted context omitted.

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

assert() is meant to be compiled away if NDEBUG is defined, otherwise it shouldn't be called assert(). Given that assert() may be compiled away, it makes sense not to give it anything that has side effects. 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://githu…

If your assert compiles down to `if (condition) {}` in production then the compiler will optimize away the condition while keeping any side effects.

Re: C++26: A User-Friednly assert() macro

#38

Post by WalterBright »

D just makes assert() part of the language:

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.

Re: C++26: A User-Friednly assert() macro

#40

Post by secondcoming »

maccard wrote: post #21
MontagFTB wrote: post #5

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.

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

Let's not vague post on HN. What's the problem with the above?
Post reply on HN