11–20 of 70 posts
__attribute__(hot)
__attribute(cold)
2. https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Label-Attribut...>; Since GCC 4.8, released March 3, 2013
This seems like it will clutter code. I wish it was more terse as I find modern C++ code bases to be way too verbose already. It starts to get straining when looking at new modules.
I believe this is the proposal that added them:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p04...
The "references" section has links to GCC and Clang builtins:
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
http://llvm.org/docs/BranchWeightMetadata.html#built-in-expe...
tl;dr: these attributes are absolutely full of footguns because the standard is not explicit about precedence and nesting, and you should probably avoid them and prefer to spend time investing in PGO. It’s very easy to make sane-looking code containing these attributes which does the exact opposite of what you intended.
Note that this issue does not exist with the equivalent C macros — those generally behave as expected. But you should probably just invest in PGO instead of static hints there, too.
This seems like it will clutter code. I wish it was more terse as I find modern C++ code bases to be way too verbose already. It starts to get straining when looking at new modules.
I understand the overall feeling but I’m not sure I understand the specific reason why you say this is making code bases more terse. Are you comparing this with the alternative of using GCC specific extensions or no definition of likely/unlikely code paths at all?
Earlier quoted context omitted.
These annotations are really only of interest in performance-critical computations. It’s another knob for library writers to use to make the libraries you use magically faster for their users. And, should be quite rare outside of libraries.
And even then they should be handled with extreme care, as they can trigger UB if used incorrectly.
This seems like it will clutter code. I wish it was more terse as I find modern C++ code bases to be way too verbose already. It starts to get straining when looking at new modules.
I suppose there is no reason you can’t profile your code and have a tool insert these hints based on actual statistics from execution.
In general the profiler is a better tool, but there are rare exceptions and if those apply to you c++ gives you the control you need.
if (unlikely_condition) {
// Don’t inline this
expensive_operation();
}
Earlier quoted context omitted.
These annotations are really only of interest in performance-critical computations. It’s another knob for library writers to use to make the libraries you use magically faster for their users. And, should be quite rare outside of libraries.
And even then they should be handled with extreme care, as they can trigger UB if used incorrectly.
This seems like it will clutter code. I wish it was more terse as I find modern C++ code bases to be way too verbose already. It starts to get straining when looking at new modules.
[[likely]] return 2;
@!l return 2;
This seems like it will clutter code. I wish it was more terse as I find modern C++ code bases to be way too verbose already. It starts to get straining when looking at new modules.
This is standardizing vendor-specific attributes that have existed for many years. The code that use these probably use some preprocessor macro to select the right builtins, and aren't going to gain much new clutter to replace those macros. I believe this is the proposal that added them: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p04... The "references" section has links to GCC and Clang builtins: https…
Except the standard’s likely and unlikely attributes invented new syntax that is not drop-in compatible with clang’s and gcc’s attributes.
Where clang and gcc would use:
if (__builtin_expect(x > 0, 1)) { … }
if (x > 0) [[likely]] { … }