F
foonathan
foonathan.net · Personal blog · on HN since 2016
Jonathan Müller writes about C++ design and language features, including constexpr, move semantics, allocation APIs, and library techniques.
What HN saysHN commenters cite it in C++ and Rust threads on move semantics and allocation, and one says it changed their view of C's malloc API.
35HN people shared it
12linked it in comments
50stories submitted
861story points
5 months agolast shared
2016people per year2026
Most-shared posts
- 1Malloc() and free() are a bad API (2022)5 people · 89 points · first shared 2022 · 27 comments on HN
- 2New integer types I’d like to see2 people · 104 points · first shared 2022 · 126 comments on HN
- 3Constexpr is a Platform (2020)2 people · 102 points · first shared 2020 · 53 comments on HN
- 4What is the unit of a text column number?2 people · 60 points · first shared 2021 · 43 comments on HN
- 5Nifty Fold Expression Tricks2 people · 33 points · first shared 2020 · 15 comments on HN
- 6Technique: Recursive Variants and Boxes2 people · 19 points · first shared 2022 · 5 comments on HN
- 7I accidentally wrote a Turing-complete parsing library2 people · 5 points · first shared 2021 · discussion on HN
- 8Replacing std:move and std:forward2 people · 4 points · first shared 2020 · discussion on HN
- 9Technique: Compile Time Code Generation and Optimization2 people · 3 points · first shared 2022 · discussion on HN
- 10Operator Precedence Is Broken2 people · 3 points · first shared 2021 · discussion on HN
- 11The CRTP Interface Technique2 people · 2 points · first shared 2021 · discussion on HN
- 12C++20’s Iterator Sentinels2 people · 2 points · first shared 2020 · discussion on HN
- 13Should we stop writing functions?2 people · 2 points · first shared 2023 · discussion on HN
- 14Destructive move2 people · first shared 2025
- 15Carbon’s most exciting feature is its calling convention1 people · 243 points · first shared 2022 · 217 comments on HN
What HN people wrote when they linked it
einpoklum · 2025-11-08
Sorry to be the nitpicker here, but - the best incremental improvement would probably have seen move-destruction instead of just moves, which keep the source object alive and force the allowance for a valid 'empty' or 'dummy' state.
See also:
* https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Alt… move designs
* https://www.foonathan.net/2017/09/destructive-move/
Jare · 2018-01-20
There's still plenty of ways to shoot yourself in the foot if you are "not careful" with the modern C++ code you write. See for example http://foonathan.net/blog/2017/03/22/string_view-temporary.html
Modern C++ has a lot of great stuff to help, but the sense of safety you get when you use Rust is something else entirely.
Calavar · 2025-07-20
> isn't even legit in modern C++. That's just move semantics. When you move it, it's gone at the old name.
Exactly the opposite actually.
Rust has destructive move while modern C++ has nondestructive move.
So in Rust, an object is dead after you move out of it, and any further attempts to use it are a compiler diagnosed error. In contrast, a C++ object is remains alive after the move, and further use of it isn't forbidden by the language, although some or all uses might be forbidden by the specific user provided move function - you'll have to reference the documentation for that move function to find out.
This article explains the difference well: https://www.foonathan.net/2017/09/destructive-move/
gpderetta · 2022-11-28
That's what everybody originally believes (me included)!
constexpr is_right_answer(int x)
{
if (x==42) return true;
else
{
std::cout <<"try again \n";
return false;
}
A function can be constexpr as long as at least one possible invocation can be compile time evaluated. In fact compilers can't generally prove that a function can't be constexpr.
I believe constinit has the semantics you want but I've yet to study it in details.
For more details see: https://www.foonathan.net/2020/10/constexpr-platform/ .
nyanpasu64 · 2022-09-19
I'm reminded of https://www.foonathan.net/2022/08/malloc-interface/#problem-4-realloc. While initially I was skeptical of the author's criticism of C's allocation APIs, this bug seems to be one that could've been avoided by using the proposed try_expand() instead of realloc().
Of course ideally we'd move away from provenance-based UB and Rust's third-class aliased mutability, to simpler conservative aliasing semantics by default, and allow programmers to opt into non-general optimizations by manually saving unchanging values like vector::size() into locals, or have the optimizer and programmer interactively explore code invariants and optimizations, making the optimizer a performance-focused pair programmer rather than a black box.
hhyndman · 2022-08-07
An interesting article relating to "operator precedence is broken". https://www.foonathan.net/2017/07/operator-precedence/
pjmlp · 2021-08-01
You can use inline namespaces for versioning symbols.
https://www.foonathan.net/2018/11/inline-namespaces/
lifthrasiir · 2021-04-09
I don't think ditching the "basic" operator precedence (MDAS etc.) is a good idea, but I strongly agree that operator precedence should be a partial order, not a total order. See also [1].
[1] https://foonathan.net/2017/07/operator-precedence/
lenkite · 2021-04-07
"Every feature you have in C++, Rust does it better"
How does one perform generic fold expressions in Rust lang ? (Possible in C++ 17 and above)
https://foonathan.net/2020/05/fold-tricks/
https://en.cppreference.com/w/cpp/language/fold
emmanueloga_ · 2021-03-27
I remember reading an article about the difficulties of extracting AST from clang [1]. Even when there are less politics involved, seems like a hard problem. With GCC, the problem becomes an Stallman order of magnitude harder :-)
1: https://foonathan.net/2017/04/cppast/
cma · 2020-12-22
I thought he was saying the `end` in range begin/end was now allowed to be some empty signifier to tell things to look for the null pointer (null is a sentinel, but `end` itself is now empty). That may not be right, I don't know enough about the new concepts stuff and range seems to be part of that.
edit: looking at this it maybe covers it:
https://foonathan.net/2020/03/iterator-sentinel/
aw1621107 · 2020-03-24
I believe programmers are still free to define specific operators in lieu of the compiler-derived ones for such cases.
I found a blog post which raised similar concerns [0], and P1185 [1] proposes some solutions. I don't know whether they made it into the standard, though.
[0]: https://foonathan.net/2018/10/spaceship-proposals/
[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1185r1.html