45 ms·
C++ Core Guidelines
- senkora 2y agoWhat's the current state of automatic enforcement of these? I know that Microsoft has built tooling to enforce a subset of them, but I'm not aware of anything for Linux that specifically targets these. https://learn.microsoft.com/en-us/cpp/code-quality/using-the-cpp-core-guidelines-checkers?view=msvc-170 https://learn.microsoft.com/en-us/cpp/code-quality/using-the...
- pjmlp 2y agoThe best tooling to have them automatically applied are VC++ and Clion. Or you can get the DevOps team to install Sonar, PVS, and then it gets "automatically" enforced by not allowing merges with broken guidelines.
- caleb-troyer 2y agoClang-tidy[0] supports a good set of them (cppcoreguidelines- prefix). It supports extending the checks too with your own checks that operate over the AST[1], so if there are extra guidelines internal to your company like mine has, there's room for extension there. For automation, I've seen a few examples of people integrating clang-tidy into IDEs, git hooks, and code review systems. [0] https://clang.llvm.org/extra/clang-tidy/ https://clang.llvm.org/extra/clang-tidy/ [1] https://github.com/coveooss/clang-tidy-plugin-examples https://github.com/coveooss/clang-tidy-plugin-examples
- dig1 2y agoIt is funny how they are still touting that C++ exceptions are/should not (be) slow and that we should "complain to your implementation purveyor" if they are. Yet, the two most used C++ compilers today with top-notch optimizations (GCC and Clang) are still slow with exceptions. Took this code [2] and tested with O2 optimizations with gcc 11.x and clang 13.x versions: $ ./exceptions-test-gcc 3906 return code errors in 0.000562 seconds 3906 exception errors in 0.005740 seconds Exceptions are 10.2x slower than return codes $ ./exceptions-test-clang 3906 return code errors in 0.000142 seconds 3906 exception errors in 0.004568 seconds Exceptions are 32.2x slower than return codes [1] https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#e6-use-raii-to-prevent-leaks https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines... [2] https://stackoverflow.com/a/78301673 https://stackoverflow.com/a/78301673
- pjmlp 2y agoBecause they don't care to apply those top notch optimizations to their exception implementation. VC++ is much faster, as it pings back into Win32 exceptions, for example.
- Maxatar 2y agoI don't want to give to much credibility to the benchmark OP posted because it is quite flawed, but MSVC performs absolutely terribly on that benchmark, far worse than GCC or clang with a 58x slowdown when compiled in 64-bit mode. I can only imagine how much worse it would be if compiled in 32-bit mode since MSVC in 32-bit mode does not use zero cost exception handling but uses a frame based, setup/teardown exception handling mechanism. The exception handling you're referring to about pinging back to Win32 I presume is structured exception handling, which is not the default exception handling mechanism used by MSVC, is not recommended to be used, and is not at all performance sensitive. This advice comes from Microsoft themselves: https://learn.microsoft.com/en-us/cpp/cpp/exception-handling-in-visual-cpp?view=msvc-170 https://learn.microsoft.com/en-us/cpp/cpp/exception-handling... The C++ exception handling mechanism that is used by default does not "ping back" into Win32.
- pjmlp 2y agoI guess my recollection was wrong then. However the point still stands, that isn't something compiler vendors see commercial value so to speak, when they are so constrained to keep up with ISO revisions, and a big slice of the customer base keeps disabling them.
- soulbadguy 2y agoIn general, yes i would agree that modern C++ compiler could do a much better job on exception enable code, especially in term of data flow analysis. But in this case, the benchmark it's self is kinda flawed. The semantic of the two code a very different so there isn't much the compiler could have (reasonably done).
- 2y ago