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

81–89 of 89 posts

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

#81

Post by IshKebab »

maccard wrote: post #78
IshKebab wrote: post #74

Earlier quoted context omitted.

Sure, but none of that is relevant to just the code snippet that was posted. The compiler can exploit UB in other code to do weird things, but that's just C being C. There's nothing unexpected in the snippet posted. The issue is cause by C declaring that dereferencing a null pointer is UB. It's not really an issue with assertions. You can get the same optimisation-removes-code for any UB.

> There's nothing unexpected in the snippet posted. > The issue is cause by C declaring that dereferencing a null pointer is UB. It's not really an issue with assertions. > You can get the same optimisation-removes-code for any UB. I disagree - It’s a 4 line toy example but in a 30-40 line function these things are not always clear. The actual problem is if you compile with NDEBUG=1, the nullptr check is removed and…

> The actual problem is if you compile with NDEBUG=1

That is entirely expected by any C programmer. Sure they named things wrong - it should have been something like `assert` (always enabled) and `debug_assert` (controlled by NDEBUG), as Rust did. And I have actually done that in my C++ code before.

But I don't think the mere fact that assertions can be disabled was the issue that was being alluded to.

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

#82

Post by maccard »

IshKebab wrote: post #81
maccard wrote: post #78

Earlier quoted context omitted.

> There's nothing unexpected in the snippet posted. > The issue is cause by C declaring that dereferencing a null pointer is UB. It's not really an issue with assertions. > You can get the same optimisation-removes-code for any UB. I disagree - It’s a 4 line toy example but in a 30-40 line function these things are not always clear. The actual problem is if you compile with NDEBUG=1, the nullptr check is removed and…

> The actual problem is if you compile with NDEBUG=1 That is entirely expected by any C programmer. Sure they named things wrong - it should have been something like `assert` (always enabled) and `debug_assert` (controlled by NDEBUG), as Rust did. And I have actually done that in my C++ code before. But I don't think the mere fact that assertions can be disabled was the issue that was being alluded to.

I wrote the comment, assertions being disabled was exactly what was being alluded to.

> that is entirely expected by any C programmer

That’s great. Every C programmer also knows to avoid all the footguns and nasties - yet we still have issues like this come up all the time. I’ve worked as a C++ programmer for 12 years and I’d say it’s probably 50/50 in practice how many people would spot that in a code review.

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

#83

Post by quuxplusone »

saagarjha wrote: post #72
pwdisswordfishy wrote: post #63

Earlier quoted context omitted.

But if the assertion fails, the program is aborted before the pointer would have been dereferenced, making it not UB. This explanation is bogus.

Only if the assert is active. It basically means that the code is invalid when NDEBUG is set.

When NDEBUG is set, there is no test, no assertion, at all. So yes, this code has UB if you set NDEBUG and then pass it a null pointer — but that's obvious. The code does exactly what it looks like it does; there's no tricks or time travel hiding here.

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

#84

Post by einpoklum »

nananana9 wrote: post #35
einpoklum wrote: post #33

Earlier quoted context omitted.

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.

None of these complaints detract from this being a terse, readable, and available using the standard library, which is what the question was about...

I will agree that std::ranges is quite a jumble of templates, and has a compilation time penalty. Perhaps the use of modules will help with that somewhat.

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

#85

Post by IshKebab »

maccard wrote: post #82
IshKebab wrote: post #81

Earlier quoted context omitted.

> The actual problem is if you compile with NDEBUG=1 That is entirely expected by any C programmer. Sure they named things wrong - it should have been something like `assert` (always enabled) and `debug_assert` (controlled by NDEBUG), as Rust did. And I have actually done that in my C++ code before. But I don't think the mere fact that assertions can be disabled was the issue that was being alluded to.

I wrote the comment, assertions being disabled was exactly what was being alluded to. > that is entirely expected by any C programmer That’s great. Every C programmer also knows to avoid all the footguns and nasties - yet we still have issues like this come up all the time. I’ve worked as a C++ programmer for 12 years and I’d say it’s probably 50/50 in practice how many people would spot that in a code review.

It's definitely a footgun, but the compiler isn't doing weird stuff because the assertions can be disabled. It's doing weird stuff because there's UB all over the place and it expects programmers to magically not make any mistakes. Completely orthogonal to this particular (fairly minor IMO) footgun.

> I’ve worked as a C++ programmer for 12 years and I’d say it’s probably 50/50 in practice how many people would spot that in a code review.

Spot what? There's absolutely nothing wrong with the code you posted.

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

#86

Post by jmalicki »

IshKebab wrote: post #85
maccard wrote: post #82

Earlier quoted context omitted.

I wrote the comment, assertions being disabled was exactly what was being alluded to. > that is entirely expected by any C programmer That’s great. Every C programmer also knows to avoid all the footguns and nasties - yet we still have issues like this come up all the time. I’ve worked as a C++ programmer for 12 years and I’d say it’s probably 50/50 in practice how many people would spot that in a code review.

It's definitely a footgun, but the compiler isn't doing weird stuff because the assertions can be disabled. It's doing weird stuff because there's UB all over the place and it expects programmers to magically not make any mistakes. Completely orthogonal to this particular (fairly minor IMO) footgun. > I’ve worked as a C++ programmer for 12 years and I’d say it’s probably 50/50 in practice how many people would spot t…

That assert could completely fail to fire if inlined into another function that did a dereference first.

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

#87

Post by WalterBright »

rurban wrote: post #75
WalterBright wrote: post #38

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 wit…

So you are ignoring our well beloved NDEBUG? :) Our idea of declare (optimize (speed 3) (safety 0))

D compilers have a "ramming speed" setting.

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

#89

Post by dataflow »

IshKebab wrote: post #70
comex wrote: post #50

Earlier quoted context omitted.

It does in Rust: assert is always enabled, whereas the debug-only version is called debug_assert. But yes, “assert” in most languages is debug-only.

He said > some people would expect it to enforce that the pointer is non-null, then proceed No language magically makes the pointer non-null and then continues. I don't even know what that would mean.

If you don't even know what that would mean then it's premature to declare that nothing works that way. Understanding the meaning is a prerequisite for that.

In this case, it may help to understand that e.g. border control enforces a traveler's permission to cross the border, then lets them proceed.

Post reply on HN