Yep.
For GNOME their are packages available for DevHelp through third parties (e.g. Archlinux->AUR). DevHelp could make good use of a direct installation option for users.
I wish Zeal made it easier to inject custom CSS based on the current docset (like Stylus in a browser lets you inject different CSS per domain), or change the zoom level independently for each docset. One pet peeve of mine is fonts I dislike or find too small/large, and browsers currently have better tools for customizing reading.
Wow, this is really good, there are still things I can learn.
C++ really has a lot of good things. It's just a shame it's so slow to compile.
I'm curious if anybody is working to make C++ faster to compile. Even if it was a subset of the language, with some features removed, it would be good enough for me.
> I'm curious if anybody is working to make C++ faster to compile.
Yes - C++20 added support for modules to the Core Language (both "header units" and "named modules"; header units are an intermediate step between classic includes and named modules), and support for header units to the Standard Library. Compiler/library support is a work in progress (MSVC's STL, which I work on, is the furthest along - see https://github.com/microsoft/STL/issues/1694 for status), but header units are showing significant improvements in compiler throughput (build speed). This looks like `import <vector>;` in your source code (with significant build system changes to build vector as a header unit, producing vector.ifc and vector.obj).
There's a proposal under review for C++23 to add named modules for the Standard Library, see https://wg21.link/p2465r2 . If this is accepted, `import std;` (or `import std.compat;`) will be the one-line way to use the entire C++ Standard Library with (what we hope will be) even better compiler throughput.
The primary limitation of header units and especially named modules is macros: neither can be influenced by macros defined in the source file, and named modules can't emit macros at all. Thus, one will still need to `#include <cassert>` in addition to `import std;` if you want the `assert()` macro.
This is all solid advice (particularly using a faster linker).
IME, the single best way to reduce your C++ compile times is to compile less code:
* Remove all unnecessary headers. Template expansion is slow, and preprocessing is even slower. Some of the standard includes (like `<regex>` and `<iostream>`) are notorious for slowing individual translation units to a crawl. `#pragma once` for your own headers also helps with cpp-time performance.
* Forward-declare as much as you can. Forward type declarations mean that the compiler doesn't need to process all of `Foo` when it sees `Foo&` or `Foo`.
Use pImpl wherever you can (and makes sense). Private implementations similarly reduce the amount of code the compiler needs to analyze.
For better or worse, the current winds suggest that C++ compilation times will only continue to get worse (more constexpr/consteval, even more complex templating features/concepts, etc.).
Constexpr improves compilation speed by the degree that it displaces template metaprogramming. Template metaprogramming runs at Python speed, where constexpr runs orders of magnitude faster. Anywhere you have a choice between them, choose constexpr.
Substantial improvement in compilation speed might depend on use of JIT techniques, running generated code in the compiler to perform template evaluation. I.e., a template is not just a data structure, it is a compile-time function that, where used much, is compiled to optimized machine code, its run-time values being what we think of as types. Thus far, all these functions are run like an interpreter walking a syntax tree.
Precompiled headers, or module intermediate files, could have this code in them already optimized.
> * Remove all unnecessary headers. Template expansion is slow, and preprocessing is even slower. Some of the standard includes (like `<regex>` and `<iostream>`) are notorious for slowing individual translation units to a crawl. `#pragma once` for your own headers also helps with cpp-time performance.
> * Forward-declare as much as you can. Forward type declarations mean that the compiler doesn't need to process all of `Foo` when it sees `Foo&` or `Foo`.
I've found the include-what-you-use (IWYU) tool [1][2] can help immensely with automating this process, especially on large code-bases.
It uses LLVM/Clang to analyze a .cpp file / translation unit and produces the minimal subset of exactly which includes are necessary and what types can be forward declared.
Yep, all of this is good advice but requires being able to change the code, which is far from a given in c++ where you may have to work with a dozen proprietary SDKs.
I personnally use clang -ftime-trace to see which headers take the most time and then Qt Creator's "find all places where this file is included" feature to try to make the most efficient cleanups
CLion from JetBrains and Microsoft Visual Code are the best commercial ones for Linux, NetBeans is a free (as in freedeom and open source) one (that also supports many other languages like Java and Python).
What I don't recommend is Eclipse - it's complex and confusing for beginners (but a bit faster than some others).
Yeah, at least according to the repo it seems they now delegate to the ccls language server and just do syntax highlighting via the textmate plist grammars that are so commonly paired with language servers
I find visual studio to be absolutely horrendous for C++. Refactoring doesn't work (even a simple rename symbol!) The errors aren't accurate, autocomplete seems to suggest every symbol from the stdlib before the class defined in the file itself and can't tell when it should suggest classes vs functions/variables.
Oh and of course compile errors are absolutely useless but I suppose that's a C++ thing in general. The error panel shows the (last? First?) Error in a chain of errors, which is always something deep in library code. E.g. accidentally tried to copy a non-copyable object using unique_ptr? You can't find the offending callsite, it just points you to xmemory and at best the class being wrongly used.
They offer binary releases, but it's also possible to compile from source without too much trouble. Written in C++, it's pretty snappy. Supports meson.
I can testify to JetBrains products, they're quite good. I haven't used CLion in a few years because I don't like depending on a dev tooling that costs money. I use VSCode because I hop between Python, Bash, Go, C, and C++. That being said, CLion definitely offers a much better debugging experience, even when VSCode has all the right plugins.
I thought that the old point of C++ mangling was that it could use existing linker tech. Do you have some references?
Also, my understanding is that, except for the very first few prototypes, starting from cfront on the C++ compiler was a real compiler. It just happened to target C instead of asm.
I'm usually not a fan of "cheat sheets" (HTML online documentation, man pages and even real books are quickly at hand) - but this is a useful (and pretty) synopsis of many useful library functions and recent additions to C++, thanks.
The sizeof(variant) example is wrong. An extra byte is needed to store the discriminator value, which in practice results in 8 extra bytes for these particular types because of alignment. https://godbolt.org/z/vno3v9rPK
The tuple drawing is also somewhat misleading, because the first box (int) should be the same size as the second one (double), due to alignment.
Other than this kind of cheat sheet, I wonder could there be a common idiom cheat sheet for situation like … for people who does not develop but have to understand and fix a minor bugs.
Sometimes you just in that hole and it is hard between the gap of knowing or trained on the basic c++ and then need to or try to understand a c++ …
This is quite something! I intend to share w/ my coworkers :)
If I had one thing I could have added to it: panel for understanding value categories[0] -- I have an incredibly hard time wrapping my head around how they're described. I attribute the difficulty to the cpp standard being excruciatingly complex, the language itself not being designed holistically, and backwards compatibility with itself and C.
Honestly, you don't have to understand value categories to this degree. The distinctions are important for writing the standard, but I've never once explained (or was explained) a line of code where diving into the depths of value categories would add anything.
In practice it boils down to "if it has a name, you need to std::move it to get move semantics, otherwise you don't". Caveats apply (e.g. returning a named value).
Probably semi related, but when I was looking at C/C++ job offers, why are they paid so little in comparison to Python or JavaScript?
It seems like C/C++ is much more complex. I was mainly looking at embedded stuff vs Web.
For example senior C++ role was paying £45k pa on average and over £60k for JS.
Difficulty of a job isn't a great metric to evaluate pay/salary, if that were the case then miners or gravediggers would be among the wealthiest people in the world. Salaries often have to do with marginal revenue productivity and from that metric, C++ is not a particularly productive programming language compared to its cost.
C++ is a very error prone, complex and risky language and even when used in industry, it's used in such a way that companies significantly restrict its feature set to a mostly sane subset of the language that in many cases looks like a dialect of C with classes. The benefit of using it is your product has the potential to outperform software written in other languages, but this benefit often comes at the cost of software that is more limited in features compared to competitors.
For some domains, like HFT, audio and graphics, where performance is the primary feature C++ does pay well, but for most other domains the sheer complexity of the language outweighs any benefit to productivity.
So ultimately the reason Python developers get paid more than C++ developers is because products developed in Python are more productive than products developed in C++. The reason for that difference in productivity is that given two developers who are both investing X units of time working a product, the Python developer is far more likely to spend that time adding new features to their product while the C++ developer is likely to spend that time trying to find the cause of some random bug due to undefined behavior, or trying to figure out some arcane and complex language quirk.
If it says "C/C++", it means they don't even know what they want, and might even be satisfied with a cave-dwelling C coder.
The highest-paid programming jobs are mainly held by C++ programmers, many of them in service of financial gambling. That work shades over into FPGA and HPC programming at the high end. A skilled C++ programmer at these shops can get a half $million, some more.
Yeah, job adverts (and resumes) with "C/C++" usually seem like they are reading off MS VisualStudio marketing and imo a clown indicator. I've seen this with jobs which were really C# or Java (or maybe even VB). Top C++ programmers are highly compensated and only unemployed when they want to be.
It has been literally decades since I last encountered it. In any case the title has exactly nothing to do with job listings or what may be inferred from them.
> Experience using scripting languages such as bash, Python, and PowerShell, or compiled languages such as C/C++, C# and Go are most relevant, but others are acceptable
"Software Engineer, Core, Compilers, Runtimes and Toolchains" @ Google
So, you are saying that clueless HR people are employed at such very large companies as NVidia, Microsoft, Google, Apple, IBM, AMD, and ARM? I'll bet you can find cigarette smokers working in them, too. And Russian Empire sympathizers.
If you ever had a point, you lost it some time ago.
There's a bunch of categories, the first one is indeed standard algorithms. Full list: Standard Algorithms, Standard Randomness, Standard Sequence Views, Standard Containers, Standard Utilities, Language Mechanisms, Libraries, Design Guidelines, Engineering, Terminology. Seems fairly comprehensive to me.
Why do these types of comments come up in every thread about C++? Sometimes people who like C++ just want to talk about C++ on the internet. It doesn't have to be for everybody.
What are you talking about exactly ? I don't see anything in there that wouldn't be great for any language. E.g. knowing complexity bounds, random distributions... Those are things you need to know when you program, before even writing a single line of code.
It does not make sense if you think you have to learn every single function in a language's standard library. And if you think you have to, you are thinking wrong of a language like C++. This sheets are just a summary of what a language is capable of, you don't have to memorize every library function just look up what you need.
It's because this cheat sheet goes in depth. That's why it's so many pages long. I would expect what you compare to does not delve into in-memory layouts of vectors and random distributions because they usually don't.
This looks aimed more for computer science students or mathematicians wanting to quickly adapt pseudeo code to C++ more than a novice wanting to see what C++ is about.
I agree, you can do a lot with C++, there's a lot of advanced libraries for different purposes, but it's simply not pleasant experience, especially, if anyone gets fancy with everything that C++ offers and you need to understand it.
Personally I want to focus on what code is doing, it's also important to understand how it's doing something, but typically I don't care that much about performance, I just want language that will produce valid code without too much effort and thousands little details that you need to be aware of and with languages like C++ you need to pay high attention to code you write and debugging can be horror story, once something goes bad.
For me, if I need to go low-level, Go is sufficient. It's readable, performant and it's harder to shot your feet with it.
Your criticisms of C++ are correct. The language is janky to use and filled with edge cases. The standard library is designed by implementers to make most things possible but few things easy (std::string::contains will be added in C++23 yay!). And using the same-ish iterator interface for vectors and hashmaps results in needlessly unsafe and verbose vector methods (foo.bar[index].insert(foo.bar[index].end(), ...)) and great difficulty implementing hashmap iterators that act like pointers.
Nonetheless the cheat sheets largely do not reflect these issues, but the breadth of functionality C++ supplies. span and string_view are simple and elegant (aside from lifetime errors caught by Rust). Personally I think algorithms try to do too much, and it's not like other languages could cram in binary search, heap algorithms, reduce, scan, permutations... in a "simple, intuitive fashion", though duplicate functionality between iterators and ranges is a problem. Arithmetic conversions and promotions were a mistake (inherited from C) though, and lambda captures and mutability are complex. Reference collapsing has a simple slide but confusing semantics. I'm not sure I see any structured bindings either (these interact poorly with lambda captures lol).
C++ overs all kind of high-level features and allow to go low-level when need. I know the core stuff and what I use regularly in addition. Will likely never learn all possibilities of C++. I don't think that is neither intended nor possible. The compiler does know all that stuff and according to my knowledge that is its purpose. Compiler, the best friend of the developers.
Nowadays the compilers talking most of the time in clear language ;)
Also, if you do not use Dash or an open source implementation like Zeal[1] (which is what I use), you are missing out.
The supplied C++ docset comes from cppreference.com and is very, very useful to have to hand.
The Python and CMake docsets are also particularly useful to me.
[1] https://zealdocs.org/
Yep. For GNOME their are packages available for DevHelp through third parties (e.g. Archlinux->AUR). DevHelp could make good use of a direct installation option for users.
A similar, online version: https://devdocs.io/
I wish Zeal made it easier to inject custom CSS based on the current docset (like Stylus in a browser lets you inject different CSS per domain), or change the zoom level independently for each docset. One pet peeve of mine is fonts I dislike or find too small/large, and browsers currently have better tools for customizing reading.
Is it worth paying the $30 for Dash? Zeal crashes one me every now and then.
Wow, this is really good, there are still things I can learn.
C++ really has a lot of good things. It's just a shame it's so slow to compile.
I'm curious if anybody is working to make C++ faster to compile. Even if it was a subset of the language, with some features removed, it would be good enough for me.
> I'm curious if anybody is working to make C++ faster to compile.
Yes - C++20 added support for modules to the Core Language (both "header units" and "named modules"; header units are an intermediate step between classic includes and named modules), and support for header units to the Standard Library. Compiler/library support is a work in progress (MSVC's STL, which I work on, is the furthest along - see https://github.com/microsoft/STL/issues/1694 for status), but header units are showing significant improvements in compiler throughput (build speed). This looks like `import <vector>;` in your source code (with significant build system changes to build vector as a header unit, producing vector.ifc and vector.obj).
There's a proposal under review for C++23 to add named modules for the Standard Library, see https://wg21.link/p2465r2 . If this is accepted, `import std;` (or `import std.compat;`) will be the one-line way to use the entire C++ Standard Library with (what we hope will be) even better compiler throughput.
The primary limitation of header units and especially named modules is macros: neither can be influenced by macros defined in the source file, and named modules can't emit macros at all. Thus, one will still need to `#include <cassert>` in addition to `import std;` if you want the `assert()` macro.
Still looking forward to a solution for _ITERATOR_DEBUG_LEVEL in release builds with modules, VS DevCommunity ticket does exist.
Currently it appears anyone that cares about bounds checking and iterator validation in release builds, has to keep using global module fragments.
I have the opposite problem. I can't use modules because I need _ITERATOR_DEBUG_LEVEL=0 in debug builds.
The standard library modules really need to be built as part of your projects build so that you can compile them however you want.
Either that, or be like MFC/ATL and provide a couple of pre-compiled versions for common workflows.
Wow, thanks, can't wait for this.
How hard will it for library writers to supply their libraries as modules?
Will the only requirement be to remove macros?
* Compile with clang, link with mold or at least lld. mold can link gigabyte-sized binaries in, like, one second
* Use ninja instead of make
* Use PCH
* -gsplit-dwarf
This is all solid advice (particularly using a faster linker).
IME, the single best way to reduce your C++ compile times is to compile less code:
* Remove all unnecessary headers. Template expansion is slow, and preprocessing is even slower. Some of the standard includes (like `<regex>` and `<iostream>`) are notorious for slowing individual translation units to a crawl. `#pragma once` for your own headers also helps with cpp-time performance.
* Forward-declare as much as you can. Forward type declarations mean that the compiler doesn't need to process all of `Foo` when it sees `Foo&` or `Foo`.
Use pImpl wherever you can (and makes sense). Private implementations similarly reduce the amount of code the compiler needs to analyze.
For better or worse, the current winds suggest that C++ compilation times will only continue to get worse (more constexpr/consteval, even more complex templating features/concepts, etc.).
Constexpr improves compilation speed by the degree that it displaces template metaprogramming. Template metaprogramming runs at Python speed, where constexpr runs orders of magnitude faster. Anywhere you have a choice between them, choose constexpr.
Substantial improvement in compilation speed might depend on use of JIT techniques, running generated code in the compiler to perform template evaluation. I.e., a template is not just a data structure, it is a compile-time function that, where used much, is compiled to optimized machine code, its run-time values being what we think of as types. Thus far, all these functions are run like an interpreter walking a syntax tree.
Precompiled headers, or module intermediate files, could have this code in them already optimized.
> * Remove all unnecessary headers. Template expansion is slow, and preprocessing is even slower. Some of the standard includes (like `<regex>` and `<iostream>`) are notorious for slowing individual translation units to a crawl. `#pragma once` for your own headers also helps with cpp-time performance.
> * Forward-declare as much as you can. Forward type declarations mean that the compiler doesn't need to process all of `Foo` when it sees `Foo&` or `Foo`.
I've found the include-what-you-use (IWYU) tool [1][2] can help immensely with automating this process, especially on large code-bases.
It uses LLVM/Clang to analyze a .cpp file / translation unit and produces the minimal subset of exactly which includes are necessary and what types can be forward declared.
[1] https://include-what-you-use.org/
[2] https://github.com/include-what-you-use/include-what-you-use
Yep, all of this is good advice but requires being able to change the code, which is far from a given in c++ where you may have to work with a dozen proprietary SDKs.
I personnally use clang -ftime-trace to see which headers take the most time and then Qt Creator's "find all places where this file is included" feature to try to make the most efficient cleanups
All good suggestions. I might add: ccache and distcc to speed up full rebuilds.
Off topic. Could you recommend an ide to work with c++?
CLion from JetBrains and Microsoft Visual Code are the best commercial ones for Linux, NetBeans is a free (as in freedeom and open source) one (that also supports many other languages like Java and Python).
What I don't recommend is Eclipse - it's complex and confusing for beginners (but a bit faster than some others).
I didn’t think NetBeans supported C++ anymore?
Yeah, at least according to the repo it seems they now delegate to the ccls language server and just do syntax highlighting via the textmate plist grammars that are so commonly paired with language servers
* https://github.com/apache/netbeans/tree/12.3/cpplite#cpplite
* https://github.com/apache/netbeans/blob/12.3/cpplite/cpplite...
Microsoft Visual Studio for Windows and QtCreator for Linux.
I find visual studio to be absolutely horrendous for C++. Refactoring doesn't work (even a simple rename symbol!) The errors aren't accurate, autocomplete seems to suggest every symbol from the stdlib before the class defined in the file itself and can't tell when it should suggest classes vs functions/variables.
Oh and of course compile errors are absolutely useless but I suppose that's a C++ thing in general. The error panel shows the (last? First?) Error in a chain of errors, which is always something deep in library code. E.g. accidentally tried to copy a non-copyable object using unique_ptr? You can't find the offending callsite, it just points you to xmemory and at best the class being wrongly used.
Compile errors will anyway be getting better as concept support gets built out.
qt-creator is a nice open-source IDE:
https://github.com/qt-creator/qt-creator
They offer binary releases, but it's also possible to compile from source without too much trouble. Written in C++, it's pretty snappy. Supports meson.
I can testify to JetBrains products, they're quite good. I haven't used CLion in a few years because I don't like depending on a dev tooling that costs money. I use VSCode because I hop between Python, Bash, Go, C, and C++. That being said, CLion definitely offers a much better debugging experience, even when VSCode has all the right plugins.
CLion is quite good IME. Visual Studio, historically, has been excellent, but I haven’t used Windows full time in a decade.
I use Qt Creator on every platform
CLion, VSCode, Vim - in order of decreasing tooling.
vim with the YouCompleteMe plugin (which uses clang-complete) is pretty good.
Contrary to a sibling post eclipse CDT is fine (especially with vim bindings).
It depends what you want from your IDE maybe?
Is clang still faster? I thought it had slowed down in the past decade and was now worse than GCC.
For my own projects at least it is, by 10-20%
to give a very flagrant example on a project that i am currently working on:
- GCC 11 build: 4m20 (https://github.com/celtera/avendish/runs/5449993123?check_su...)
- Clang 14 build: 2m40 (https://github.com/celtera/avendish/runs/5449993033?check_su...)
Had the same experience. It is not a huge difference, but it is noticeable, especially in the incremental edit-build-test cycle.
In the old days C++ pre-processed into C. Then you had to run a special linker to handle how the preprocessor created class part names.
I thought that the old point of C++ mangling was that it could use existing linker tech. Do you have some references?
Also, my understanding is that, except for the very first few prototypes, starting from cfront on the C++ compiler was a real compiler. It just happened to target C instead of asm.
In a similar vein: I've had the "initialization in C++17" chart taped above my desk for a 3 years now[1].
[1]: https://timur.audio/initialisation-in-c17-the-matrix
Forrest Gump learns C++ Initialization is better :
https://i.imgur.com/3wlxtI0.gifv
This is fantastic, thanks!
I'm usually not a fan of "cheat sheets" (HTML online documentation, man pages and even real books are quickly at hand) - but this is a useful (and pretty) synopsis of many useful library functions and recent additions to C++, thanks.
The sizeof(variant) example is wrong. An extra byte is needed to store the discriminator value, which in practice results in 8 extra bytes for these particular types because of alignment. https://godbolt.org/z/vno3v9rPK
The tuple drawing is also somewhat misleading, because the first box (int) should be the same size as the second one (double), due to alignment.
You are right. That was probably dumbed down too much. I'll fix it.
Other than this kind of cheat sheet, I wonder could there be a common idiom cheat sheet for situation like … for people who does not develop but have to understand and fix a minor bugs.
Sometimes you just in that hole and it is hard between the gap of knowing or trained on the basic c++ and then need to or try to understand a c++ …
Or JavaScript.
This seems quite useful even for a beginner because it provides a "view of the landscape".
This is quite something! I intend to share w/ my coworkers :)
If I had one thing I could have added to it: panel for understanding value categories[0] -- I have an incredibly hard time wrapping my head around how they're described. I attribute the difficulty to the cpp standard being excruciatingly complex, the language itself not being designed holistically, and backwards compatibility with itself and C.
[0] https://en.cppreference.com/w/cpp/language/value_category
Honestly, you don't have to understand value categories to this degree. The distinctions are important for writing the standard, but I've never once explained (or was explained) a line of code where diving into the depths of value categories would add anything.
In practice it boils down to "if it has a name, you need to std::move it to get move semantics, otherwise you don't". Caveats apply (e.g. returning a named value).
Regarding value categories, maybe this is also useful: https://raw.githubusercontent.com/jeaye/value-category-cheat...
Probably semi related, but when I was looking at C/C++ job offers, why are they paid so little in comparison to Python or JavaScript? It seems like C/C++ is much more complex. I was mainly looking at embedded stuff vs Web. For example senior C++ role was paying £45k pa on average and over £60k for JS.
Difficulty of a job isn't a great metric to evaluate pay/salary, if that were the case then miners or gravediggers would be among the wealthiest people in the world. Salaries often have to do with marginal revenue productivity and from that metric, C++ is not a particularly productive programming language compared to its cost.
C++ is a very error prone, complex and risky language and even when used in industry, it's used in such a way that companies significantly restrict its feature set to a mostly sane subset of the language that in many cases looks like a dialect of C with classes. The benefit of using it is your product has the potential to outperform software written in other languages, but this benefit often comes at the cost of software that is more limited in features compared to competitors.
For some domains, like HFT, audio and graphics, where performance is the primary feature C++ does pay well, but for most other domains the sheer complexity of the language outweighs any benefit to productivity.
So ultimately the reason Python developers get paid more than C++ developers is because products developed in Python are more productive than products developed in C++. The reason for that difference in productivity is that given two developers who are both investing X units of time working a product, the Python developer is far more likely to spend that time adding new features to their product while the C++ developer is likely to spend that time trying to find the cause of some random bug due to undefined behavior, or trying to figure out some arcane and complex language quirk.
If it says "C/C++", it means they don't even know what they want, and might even be satisfied with a cave-dwelling C coder.
The highest-paid programming jobs are mainly held by C++ programmers, many of them in service of financial gambling. That work shades over into FPGA and HPC programming at the high end. A skilled C++ programmer at these shops can get a half $million, some more.
Yeah, job adverts (and resumes) with "C/C++" usually seem like they are reading off MS VisualStudio marketing and imo a clown indicator. I've seen this with jobs which were really C# or Java (or maybe even VB). Top C++ programmers are highly compensated and only unemployed when they want to be.
"C/C++ Users Journal" - https://en.wikipedia.org/wiki/C/C%2B%2B_Users_Journal
You are certainly acquaited with it.
It has been literally decades since I last encountered it. In any case the title has exactly nothing to do with job listings or what may be inferred from them.
Ok, lets get job listings then, from companies whose staff seat at ISO C++.
"Senior C/C++ Software Engineer" @ NVidia
https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCar...
"Senior Software Engineer" @ Microsoft
https://careers.microsoft.com/us/en/job/1152962/Senior-Softw...
> Experience using scripting languages such as bash, Python, and PowerShell, or compiled languages such as C/C++, C# and Go are most relevant, but others are acceptable
"Software Engineer, Core, Compilers, Runtimes and Toolchains" @ Google
https://careers.google.com/jobs/results/72312064984392390-so...
> Experience with software development using C/C++.
"Software Developer (C/C++)" @ Apple
https://jobs.apple.com/en-us/details/200287299/software-deve...
"Software Developer – C/C++" @ IBM
https://careers.ibm.com/job/14295385/software-developer-c-c-...
"Principal Software Architect : C/C++/GPU" @ AMD
https://jobs.amd.com/job/Markham-Software-Development-Engine...
"Senior Compiler Engineer" @ ARM
https://careers.arm.com/job/cambridge/senior-compiler-engine...
> Excellent programming skills in C/C++
Better not keep using programming languages tainted by quality standards of all ISO C++ member companies.
So, you are saying that clueless HR people are employed at such very large companies as NVidia, Microsoft, Google, Apple, IBM, AMD, and ARM? I'll bet you can find cigarette smokers working in them, too. And Russian Empire sympathizers.
If you ever had a point, you lost it some time ago.
This is more a function of the sector. Embedded just does not pay as much as web ATM.
FAANG and FAANG-adjacent companies will pay way more than that for a senior C++ developer in London (they will also pay more for a web developer).
And of course there is the City.
The actual salaries are unfortunately usually not advertised.
Looks like cauchy_distribution chart curve annotations are wrong?
Yeah, that was a stupid copy & paste bug. I fixed it.
Cheat sheets are so incredibly useful.
All documentation would be so much better if it came with cheatsheets you could quickly scan for things that you might need.
I wonder why they are so rare...
This is very good. Is it possible to get this in a print-friendly format?
This is a great site!
Thanks for putting in all the hard work and sharing with the community.
You're most welcome. I'm glad if people like it and find it useful. If you want to be notified of updates you can follow @hackingcpp on Twitter.
wow, this is really fantastic! The whole site seems quite useful in fact.
Very good resource
This should be titled "C++ Algorithms Library Cheat Sheet". It is specifically about the algorithms functions in the standard library.
There's a bunch of categories, the first one is indeed standard algorithms. Full list: Standard Algorithms, Standard Randomness, Standard Sequence Views, Standard Containers, Standard Utilities, Language Mechanisms, Libraries, Design Guidelines, Engineering, Terminology. Seems fairly comprehensive to me.
Learned C++ in school. Dont ever want to go back to it. It's just too complicated.
This is why I love c++
hugged
Why do these types of comments come up in every thread about C++? Sometimes people who like C++ just want to talk about C++ on the internet. It doesn't have to be for everybody.
Just flag and move on. There is no point to be dragged in flame wars for every C++ submission.
What are you talking about exactly ? I don't see anything in there that wouldn't be great for any language. E.g. knowing complexity bounds, random distributions... Those are things you need to know when you program, before even writing a single line of code.
Surely you agree that the same slide (https://hackingcpp.com/cpp/std/sequence_containers.png) for any JVM or CLR language would be much longer ?
In fact, similar kind of information would be welcomed in any programming language.
It does not make sense if you think you have to learn every single function in a language's standard library. And if you think you have to, you are thinking wrong of a language like C++. This sheets are just a summary of what a language is capable of, you don't have to memorize every library function just look up what you need.
It's because this cheat sheet goes in depth. That's why it's so many pages long. I would expect what you compare to does not delve into in-memory layouts of vectors and random distributions because they usually don't.
This looks aimed more for computer science students or mathematicians wanting to quickly adapt pseudeo code to C++ more than a novice wanting to see what C++ is about.
I agree, you can do a lot with C++, there's a lot of advanced libraries for different purposes, but it's simply not pleasant experience, especially, if anyone gets fancy with everything that C++ offers and you need to understand it.
Personally I want to focus on what code is doing, it's also important to understand how it's doing something, but typically I don't care that much about performance, I just want language that will produce valid code without too much effort and thousands little details that you need to be aware of and with languages like C++ you need to pay high attention to code you write and debugging can be horror story, once something goes bad.
For me, if I need to go low-level, Go is sufficient. It's readable, performant and it's harder to shot your feet with it.
What simple languages, Python?
My pocket reference for Python 1.6 already has several pages, let alone an updated version for 3.9.
Your criticisms of C++ are correct. The language is janky to use and filled with edge cases. The standard library is designed by implementers to make most things possible but few things easy (std::string::contains will be added in C++23 yay!). And using the same-ish iterator interface for vectors and hashmaps results in needlessly unsafe and verbose vector methods (foo.bar[index].insert(foo.bar[index].end(), ...)) and great difficulty implementing hashmap iterators that act like pointers.
Nonetheless the cheat sheets largely do not reflect these issues, but the breadth of functionality C++ supplies. span and string_view are simple and elegant (aside from lifetime errors caught by Rust). Personally I think algorithms try to do too much, and it's not like other languages could cram in binary search, heap algorithms, reduce, scan, permutations... in a "simple, intuitive fashion", though duplicate functionality between iterators and ranges is a problem. Arithmetic conversions and promotions were a mistake (inherited from C) though, and lambda captures and mutability are complex. Reference collapsing has a simple slide but confusing semantics. I'm not sure I see any structured bindings either (these interact poorly with lambda captures lol).
Feels fluid for me :)
C++ overs all kind of high-level features and allow to go low-level when need. I know the core stuff and what I use regularly in addition. Will likely never learn all possibilities of C++. I don't think that is neither intended nor possible. The compiler does know all that stuff and according to my knowledge that is its purpose. Compiler, the best friend of the developers. Nowadays the compilers talking most of the time in clear language ;)
Everything is simple once you know it. The struggles I have with python would be hilarious if it wasn't so frustrating.
Not saying that C++ isn't much, or has lots of baggage.