3 ms·
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 m
by corysama 3y ago
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.
- pjmlp 3y agoAnd even then they should be handled with extreme care, as they can trigger UB if used incorrectly.
- Leherenn 3y agoDo you have examples? It's not clear from the article how you could have a UB with them.
- pjmlp 3y agoIf 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 https://youtu.be/TDKqAWtvH9c?si=b5quQkMe7XUvBbG7
- fluoridation 3y agoCould 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.
- uglycoyote 3y agoCompilers 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)?
- plorkyeran 3y agoSome attributes can cause UB (most obviously [[unreachable]] in a spot that's reachable), but [[likely]] and [[unlikely]] can't.