simpler approach to removing the C++ lib dependency at runtime#962
simpler approach to removing the C++ lib dependency at runtime#962
Conversation
|
@pauldreik We can make this close to neutral as far as lines of code are concerned. Most of the changes you see have to do with the switch from The failing tests thus far are unused functions, not real failures. |
|
@pauldreik Most of the changes are now due to the C++11 to C++17 upgrade. |
|
this looks pretty good! looking at it now. |
|
@pauldreik I am now marking this PR as 'ready to review'. With my latest changes, the 'no C++ lib' part comes really very much for free because we allow anyone to use static initializers. Note this PR, once merged, would require a MAJOR version as we are bumping up the C++ version to C++17. |
|
Note that this still requires that the C++ stdlib headers are somewhere, whereas my branch did not. My build environment doesn't have access to C++ headers at all so things like |
pauldreik
left a comment
There was a problem hiding this comment.
Nice work!
Just had some minor remarks. I think this turned out very good and I am happy we move to C++17.
I tested out some examples and it (unsurprisingly) works as promised.
|
my local install of spelling does not work properly, but I think this change would fix the spelling ci error: commit 065bb32c0c2d364adc33ebb2e137069d25badb64 (HEAD -> nostdcxx)
Author: Paul Dreik <[email protected]>
Date: Tue Apr 21 19:15:19 2026 +0200
update spell check word list
diff --git a/scripts/check_typos.sh b/scripts/check_typos.sh
index 1befba01..7ac5de65 100755
--- a/scripts/check_typos.sh
+++ b/scripts/check_typos.sh
@@ -8,6 +8,6 @@ set -eu
# this exits with nonzero status if it finds something, which terminates the script
codespell \
--skip="./benchmarks/competition,./build,./fuzz/work" \
- -L vie,persan,fo,ans,larg,indx,shft,carryin
+ -L vie,persan,fo,ans,larg,indx,shft,carryin,statics
echo "no typos detected!" |
|
@mitchellh Fair comment. I would submit to you that not requiring the C++ library at runtime ought to be the main point. Do you disagree ? The C++ headers are tiny by modern standards and you need the C++ compiler anyhow at build time. Users who build their own software, like Gentoo users, will assuredly have the C++ headers. The standard Zig tar ball can compile C++, and it contains the C++ headers. For us, the downsides of having to code in C++ without even the C++ standard headers is quite significant long term. Reimplementing and maintaining the equivalent of the standard headers is not fun. And risky. This being said, I bet you can just strap on the minimal set of C++ headers required. My estimation is that it should fit in about 500 kB. It is about the same size as the size of the HTML page (just the HTML) that we are reading now. Or about the same size as the Importantly, the standard headers are not needed at runtime (ever). Only at compile time. |
|
@mitchellh I would invite your feedback before I merge this. |
mitchellh
left a comment
There was a problem hiding this comment.
I think its a fair tradeoff to require the C++ headers. I'm significantly more concerned with the runtime requirements and not the build time ones. Thumbs up from me. Thanks for carrying this through.
|
I am going to release. Feel free to take credit on your blog. Though I did not go with your PR as-is, this current PR would have been impossible without yours... for obvious reasons. I just worked out from the same ideas. |
This is an alternative to #959 proposed by @mitchellh
It is AI generated with my guidance. Don't worry about the CI tests, this is a proof of concept.std::string_view. This is a breaking change. It means requiring C++17 and up from now.__cxa_pure_virtual. Made optional with a macro.toBinaryStringand some other legacy functions.And that's it!!!
I get...
Let us try it out by hand. Run the amalgamation script, then do...
Compare with old way:
So @pauldreik, here is my proposal...
std::stringtostd::string_view. This will break some code but very little. Few of our users ever grab our strings. It requires switching to C++17, but that ought to be fine.I think that my version has only a localized effect and it does not make the code much more difficult to maintain. It will only be an issue when adding new kernels, but it is already a bit tricky to do and not something we will do often. (New CPU families are not common.)
Update: I added
__glibcxx_assert_failas a weak symbol.