doc: note that you can assume C++20. #30136

rustyrussell commented at 2:13 AM on May 18, 2024: contributor

We check this in configure.ac, line 99:

dnl Require C++20 compiler (no GNU extensions)

This was introduced in:

commit fa67f096bdea9db59dd20c470c9e32f3dac5be94
Author: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
Date:   Sun Aug 27 10:45:39 2023 +0200

    build: Require C++20 compiler

Which git says was before v27.0rc1:

$ git describe --contains fa67f096bdea
v27.0rc1~224^2~4

doc: note that you can assume C++20.

We check this in configure.ac, line 99:

	dnl Require C++20 compiler (no GNU extensions)

This was introduced in:

	commit fa67f096bdea9db59dd20c470c9e32f3dac5be94
	Author: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
	Date:   Sun Aug 27 10:45:39 2023 +0200

	    build: Require C++20 compiler

Which git says was before v27.0rc1:

	$ git describe --contains fa67f096bdea
	v27.0rc1~224^2~4

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

f00801c5fc

DrahtBot commented at 2:13 AM on May 18, 2024: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept ACK	epiccurious

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

DrahtBot added the label Docs on May 18, 2024

in doc/developer-notes.md:774 in f00801c5fc

 770 | @@ -771,6 +771,8 @@ Wallet
 771 |  General C++
 772 |  -------------
 773 |  
 774 | +As of v27.0, we require a compiler which meets at least the C++20 standard.

laanwj commented at 2:33 AM on May 18, 2024:

It's useful to document what version of the C++ standard can be used, but i don't think this needs to mention the version it was introduced (the document always applies to the branch it is in), nor is this really the place for documenting a compiler requirement (there's dependencies.md for that).

Would word it as "Code needs to adhere to the C++20 standard.".

edilmedeiros commented at 7:42 PM on May 18, 2024:

Would word it as "Code needs to adhere to the C++20 standard.".

I second this.

rustyrussell commented at 1:26 AM on May 19, 2024:

Sure, wasn't sure this was the place, but is there somewhere better? Seems like all the regulars "know" this, so putting it where a beginner might look is helpful.

Was thinking the version info is useful for backporting, but that's a limited window and is already in the commit message if people want.

edilmedeiros commented at 1:49 AM on May 19, 2024:

I think adding this info here as you propose with the wording suggested by @laanwj would have some chance to be merged (I would ack it).

PS: edited as I realized part of my comment was not adding to the PR itself.

rustyrussell commented at 8:17 PM on May 21, 2024:

Ah, I see what you're saying. I was prefer "you can assume c++20" (which was my issue, using <bit>, not "you must meet c++20" which implies you understand all nuances of C++ standards?

laanwj commented at 12:43 PM on May 23, 2024:

Sure, i'm fine with wording it in a way that doesn't imply people understand all nuances, say "The code can use the C++20 standard.", but due to the context it should be a statement about the code, not a compiler requirement.

ajtowns commented at 1:41 AM on May 26, 2024:

"you can assume c++20"

Note that it depends on compiler support for the individual features; for instance modules are nominally part of C++20, but still have pretty poor compiler support, so aren't something we can make use of. Conversely, sometimes if a feature is widely supported by compilers/libs, we'll use it even if it's not part of the current language standard (eg #24531 #25472).

In that context, not sure if documenting C++20 is all that helpful; if you're unsure, seems better to ask ("Discuss project-specific development on #bitcoin-core-dev on Libera Chat" per doc/README.md). No particular objection either though.

which was my issue, using <bit>,

For <bit> in particular, that feature's been pulled in by #29085 a few months ago. The C++20 PR was #28349 and discussion was in #23363 since they don't seem to have already been mentioned here.

laanwj commented at 8:19 AM on May 26, 2024:

Right, in practice not even all C++11 features are fully supported, nor always desirable, e.g. don't thread_local unless it's for a very good reason and only for POD types. But as starting point before listing all the exceptions i think it still makes sense to mention.

E.g. to mention an extreme, if you write code in a purely C++98 way it's likely to get rejected on review.

epiccurious commented at 11:45 AM on May 23, 2024: contributor

Concept ACK f00801c5fc7ed18518de64dea03b96d7585523ab.

bitcoin deleted a comment on Jun 6, 2024

achow101 requested review from Sjors on Oct 15, 2024

achow101 commented at 2:53 PM on October 15, 2024: member

Is this still relevant after cmake?

maflcko commented at 2:58 PM on October 15, 2024: member

For reference, CMake has this documented as set(CMAKE_CXX_STANDARD 20) and also fails if it is violated.

maflcko commented at 2:12 PM on October 30, 2024: member

Closing for now, due to inactivity since May. (The feedback was waiting to be addressed since then)

Please leave a comment if you want this reopened, or you can open a new pull request with the new changes.

maflcko closed this on Oct 30, 2024

edilmedeiros commented at 6:20 PM on October 30, 2024: contributor

Looks like this is not relevant anyway after merging the cmake build. Lack of this info in the docs doesn't seem to be an issue.

bitcoin locked this on Oct 30, 2025