I was very surprised yesterday to find out that Unreal Engine now offers native linux builds as well as linux targets. Works flawlessly too. So with all the hate linux seems to be getting from them from what you read in the occasional blog post, they must have devs working only on this support.
Turns out you were the hacker all along
Which problems did you experienced?
ccache folder size started becoming huge. And it just didn’t speed up the project builds, I don’t remember the details of why.
This might be the reason ccache only went so far in your projects. Precompiled headers either prevent ccache from working, or require additional tweaks to get around them.
Right, that might have been the reason.
To each its own, but with C++ projects the only way to not stumble upon lengthy build times is by only working with trivial projects. Incremental builds help blunt the pain but that only goes so far.
When I tried it I was working on a 100+ devs C++ project, 3/4M LOC, about as big as they come. Compilation of everything from scratch was an hour at the end. Switching to lld was a huge win, as well as going from 12 to compilation 24 threads. The code-base in a way you don’t need to build everything to work on a specific part, using dynamically loaded libraries to inject functionality in the main app.
I was a linux dev there, the pch’s worked, not as well as for MSVC where they made a HUGE difference. Otoh lld blows the microsoft linker out of the water, clean builds were faster on msvc, incremental faster on linux.
I’ve had mixed results with ccache myself, ending up not using it. Compilation times are much less of a problem for me than they were before, because of the increases in processor power and number of threads. This together with pchs and judicously forward declaring and including only what you use.
From the times Circle surfaces in discussions, I think I remember reading it’s it not being open source that is holding back adoption? Not sure, anyway as a C++ dev i’d love to see one of the different approaches to fundamentally improving C++ take widespread hold.
Such gains by limiting included headers is surprising to me, as it’s the first thing anyone would suggest doing. Clang-tidy hints in QtCreator show warnings for includes that are not used. For me this works pretty well to keep build times due to headers under control. I wonder, if reducing the amount of included headers already yields such significant gains, what other gains can be had, and what LOC we’re talking about. I’ve seen dramatic improvements by using pch for instance. Or isolating boost usage.
I mean harmless in a way that using std::move on the return type doesn’t prevent RVO?
That sounds great!
I agree with what you’re saying even though I do think a lot of C++'s bad rep comes either from C or from pre-C++11 code. I also think that modern code should include clang-tidy in the CI, and if so at least simple mistakes like in OPs code would be flagged with “warning: Use of memory after it is freed [clang-analyzer-cplusplus.NewDelete]”
https://clang-tidy.godbolt.org/z/8E169bons
Note that all of the warnings in there are valid and should be fixed, so it’s not like wading through a see of false positives. That being said, the post is interesting in its explanation of why the example does what it does. Too bad all of the other stuff in there is bonkers.
I wonder if the language could be updated so these extra std::move invocations actually become harmless? return std::move is something that I see used quite a bit.
BOOST_OUTCOME_TRYX may be what you’re looking for. It’s only available on gcc and clang though.
Cross-platform and performant, are there options besides C++ and rust?