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?

They're saying the opposite - that it makes code bases more verbose.

I think C++ really just has bad defaults for many of its features. It's understandable given the age of the language, but I wish compiler developers would agree on a set of new default attributes for various language features and make a flag to enable them. That way, older style code can still compile but newer code isn't cursed with explicit attribute hell.

That will never happen given how many compilers exist, each with its own set of use cases.

They can agree at ISO level but even then it isn't enough, as proven by the whole set of issues that are currently being ignored on platforms where breaking the ABI is tabu.

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.

Compilers have always been making guesses about what the most likely code path is behind the scenes, but it still needs to behave correctly in the case where it was wrong (that will just be the less-optimal code path). All these attributes are doing is helping the compiler know instead of guess what the hot path is. if there is any way to confuse the compiler into giving undefined behavior with hints like this, that's a compiler bug. (not saying compiler bugs don't exist, but are you aware of a specific bug like this)?

Do you have examples? It's not clear from the article how you could have a UB with them.

If I remember correctly, Timur Doumler does some remarks on that sense on his presentation:

"Standard Attributes in C and C++"

https://youtu.be/TDKqAWtvH9c?si=b5quQkMe7XUvBbG7

Could you least give some timestamps? It's nearly two hours.

Anyway, while it is possible that some attributes can cause UB if misused, I very much doubt that's possible with [[likely]] and [[unlikely]], as they are just hints for the optimizer, and the optimizer is supposed to preserve semantical guarantees.

Some attributes can cause UB (most obviously [[unreachable]] in a spot that's reachable), but [[likely]] and [[unlikely]] can't.

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.

If you are relying on profile-directed optimization, the hints are almost surely redundant.

These are useful when there’s static knowledge about control flow that could assist the optimizer, e.g. with inlining decisions.

For example: It’s not uncommon to have “bi-modal” functions, where simple checks guard simple actions, followed by much more complex logic to handle everything else.

Are those checks for exceptional cases like an invariant violation? Think of an I/O write function confirming the device is open.

Or are they the “fast path” for the most common invocations? Think of std::vector::push_back() checking for available capacity.

The answer helps the optimizer immensely in deciding whether to “partially inline” the simple code into callers or not.

Sometimes the important performance critical path is the one least taken. You can't profile because the profiler has no way to know you don't care about the common path.

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.

In my experience PGO is absolute garbage (for languages like C and C++). For complex programs all it does is bloat the code with no measurable benefit. And for every set of inputs where it improves performance there is another where it introduces slowdowns.

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://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

http://llvm.org/docs/BranchWeightMetadata.html#built-in-expe...

> This is standardizing vendor-specific attributes

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)) { … }

the standard uses:

  if (x > 0) [[likely]] { … }

It's definitely an unconventional syntax. In addition to the above, OpenMP and shader languages annotate the branch statement for parallelism or branch/predication hints. I can't think of precedent for C++ putting the hints in the branch targets. It does have some advantages, but it's not very intuitive. The first time I tried to use the new hints I did [[likely]] if(), which of course did nothing.

Doesn't look like it. The attribute goes on branches. This goes in the middle of basic blocks. Doesn't seem better to me, might try to find the rationale for the invention instead of standardising existing practice. That proposal shows the existing attributes with different syntax.

Any suggestions on how it could be terser while still being readable? If you're reading a new module using the functionality, would you prefer seeing

    [[likely]] return 2;

or

    @!l return 2;

? Which one is more understandable if you're reading and not familiar to the syntax?