carries_dependency is the one attribute where I have absolutely no idea what it means or does was kinda hoping this video would explain it but I guess I'm not the only one who has problems with understanding it
Isn't carries_dependency more or less deprecated anyway? It only applies to memory order consume, which is not implemented by any compiler and instead lifted to "acquire " . Additional since C++17 the standard says: "The specification of release-consume ordering is being revised, and the use of memory_order_consume is temporarily discouraged. "
And it not producing any diagnostic if you misuse it shows the standards guys don't understand it either. Seriously how in the absolute f can you standardize something which you yourself have no idea how its supposed to work
9:24 It is annoying, but you can use [[msvc::no_unique_address]] instead and it does work as expected, so I typically use a macro based on compiler detection.
I mainly use [[maybe_unused]] in front of RAII lock objects where I do not always want the type to be maybe_unused but in many simple cases I do. So I often have: [[maybe_unused]] acquire_t lock(resource);
Already said this somewhere, using a macro like M_EXPECT( condition ) that converts to assert( condition ) in DEBUG, and assume( condition ) in RELEASE is something I am looking for to try.
Thank you very much for this amazing compilation ❤ so great to have them all together like this together with your insights about importance and frequency
Very interesting, do the [[likely]]/[[unlikely]] also generate branch hints(on cpus that still support them, last time i used something like that was on ps3)
🎯 Key Takeaways for quick navigation: 00:00 *🎙️ Introduction to Attributes* - Overview of upcoming discussion on attributes in C++ up to C++23. - Mention of a C++ Best Practices class being taught by the host. - Introduction to the first attribute [[noreturn]] and its purpose in signaling that a function will not return. 01:23 *🏷️ Understanding [[carries_dependency]] Attribute* - Explanation of the [[carries_dependency]] attribute and its use cases. - Highlighting the poorly understood nature of the attribute. - Discussion on the requirement of where the attribute must appear in code for it to be valid. 04:16 *🚨 Handling Deprecated Functions* - Overview of the [[deprecated]] attribute and its purpose in flagging deprecated functions. - Explanation of how using deprecated functions triggers warnings, potentially leading to hard compile failures. - Discussion on marking functions as deprecated to guide users towards safer alternatives. 05:12 *🛑 Understanding [[fallthrough]] in Switch Statements* - Explanation of the [[fallthrough]] attribute and its role in switch statements. - Demonstration of how the attribute helps prevent common bugs in switch statements. - Discussion on intentionally using [[fallthrough]] to indicate intended behavior. 06:34 *📜 Signifying Intent with [[nodiscard]] and [[maybe_unused]]* - Overview of the [[nodiscard]] attribute and its use in signaling that a function's return value should not be ignored. - Explanation of how [[nodiscard]] can also be applied to types. - Introduction of [[maybe_unused]] and its role in addressing unused variables. 08:05 *📊 Providing Optimization Hints with [[likely]] and [[unlikely]]* - Discussion on the[[likely]] and [[unlikely]] attributes and their impact on compiler optimizations. - Demonstration of how these attributes influence compiler behavior based on branch likelihood. - Highlighting their role in optimizing code performance. 09:28 *🔄 Optimizing Memory Layout with [[no_unique_address]]* - Explanation of [[no_unique_address]] attribute and its purpose in optimizing memory layout. - Demonstration of collapsing empty objects within a struct. - Mention of Visual Studio's handling of [[no_unique_address]]. 11:50 *🔍 Making Assumptions with [[assume]]* - Introduction to the [[assume]] attribute and its role in allowing the compiler to make assumptions about values during execution. - Demonstration of how [[assume]] influences generated code. - Cautionary note on the potential for [[assume]] to lead to undefined behavior. Made with HARPA AI
He was a bit unclear at that part. Any code you write after calling a noreturn function is considered to be dead code because that function will not be left through a return, only through a long jump or through exiting the program. With void everything you write after the function call just gets executed after the function returns.
Last time I checked, if I remember correctly, it was meant to be implemented with the new concepts of senders/receivers. They didn't want to just make another wrapper over OS sockets. It'll probably take a while (hopefully C++26, but who knows...). But it'll not happen until the senders/receivers and/or a proper asynchronous API/*the* async API is done. Look into P2300 proposal.
I would just use ASIO today if you really want networking. Whatever version gets included in C++ will end up out of date quickly as it can only be fixed / updated every 3 years.
carries_dependency is the one attribute where I have absolutely no idea what it means or does was kinda hoping this video would explain it but I guess I'm not the only one who has problems with understanding it
Isn't carries_dependency more or less deprecated anyway? It only applies to memory order consume, which is not implemented by any compiler and instead lifted to "acquire " . Additional since C++17 the standard says: "The specification of release-consume ordering is being revised, and the use of memory_order_consume is temporarily discouraged. "
And it not producing any diagnostic if you misuse it shows the standards guys don't understand it either. Seriously how in the absolute f can you standardize something which you yourself have no idea how its supposed to work
@@TheMrKeksLp It's a very hard problem, even a trivial optimization could potentially break the ordering.
Yeah... sorry about that :D
@@TsvetanDimitrov1976 Not wrong, but sometimes the c++ standard guys should just NOT standardize it then :D
9:24 It is annoying, but you can use [[msvc::no_unique_address]] instead and it does work as expected, so I typically use a macro based on compiler detection.
It'll be an interesting experiment to see if [[assume]] the length of a std::vector is a multiple of 8 or 16 helps get range-based code vectorized
MSVC STL doesn't multiply by 2 though. It multiplies by 1.5 as far as I know.
@@ohwow2074 Different issue. Vectorization depends on length and alignment of the data, not how much additional capacity there might be.
I mainly use [[maybe_unused]] in front of RAII lock objects where I do not always want the type to be maybe_unused but in many simple cases I do. So I often have: [[maybe_unused]] acquire_t lock(resource);
Already said this somewhere, using a macro like M_EXPECT( condition ) that converts to assert( condition ) in DEBUG, and assume( condition ) in RELEASE is something I am looking for to try.
Thank you very much for this amazing compilation ❤ so great to have them all together like this together with your insights about importance and frequency
worth noting that nodiscard also supports a message, and I believe there is something like always_inline, but maybe that predates C++11? 🤔
Very interesting, do the [[likely]]/[[unlikely]] also generate branch hints(on cpus that still support them, last time i used something like that was on ps3)
I think the likely/unlikely is primarily (maybe solely) about how the code is ordered (which may affect the instruction cache/cache misses).
This is entirely compiler dependent as to what they do or don't do.
🎯 Key Takeaways for quick navigation:
00:00 *🎙️ Introduction to Attributes*
- Overview of upcoming discussion on attributes in C++ up to C++23.
- Mention of a C++ Best Practices class being taught by the host.
- Introduction to the first attribute [[noreturn]] and its purpose in signaling that a function will not return.
01:23 *🏷️ Understanding [[carries_dependency]] Attribute*
- Explanation of the [[carries_dependency]] attribute and its use cases.
- Highlighting the poorly understood nature of the attribute.
- Discussion on the requirement of where the attribute must appear in code for it to be valid.
04:16 *🚨 Handling Deprecated Functions*
- Overview of the [[deprecated]] attribute and its purpose in flagging deprecated functions.
- Explanation of how using deprecated functions triggers warnings, potentially leading to hard compile failures.
- Discussion on marking functions as deprecated to guide users towards safer alternatives.
05:12 *🛑 Understanding [[fallthrough]] in Switch Statements*
- Explanation of the [[fallthrough]] attribute and its role in switch statements.
- Demonstration of how the attribute helps prevent common bugs in switch statements.
- Discussion on intentionally using [[fallthrough]] to indicate intended behavior.
06:34 *📜 Signifying Intent with [[nodiscard]] and [[maybe_unused]]*
- Overview of the [[nodiscard]] attribute and its use in signaling that a function's return value should not be ignored.
- Explanation of how [[nodiscard]] can also be applied to types.
- Introduction of [[maybe_unused]] and its role in addressing unused variables.
08:05 *📊 Providing Optimization Hints with [[likely]] and [[unlikely]]*
- Discussion on the[[likely]] and [[unlikely]] attributes and their impact on compiler optimizations.
- Demonstration of how these attributes influence compiler behavior based on branch likelihood.
- Highlighting their role in optimizing code performance.
09:28 *🔄 Optimizing Memory Layout with [[no_unique_address]]*
- Explanation of [[no_unique_address]] attribute and its purpose in optimizing memory layout.
- Demonstration of collapsing empty objects within a struct.
- Mention of Visual Studio's handling of [[no_unique_address]].
11:50 *🔍 Making Assumptions with [[assume]]*
- Introduction to the [[assume]] attribute and its role in allowing the compiler to make assumptions about values during execution.
- Demonstration of how [[assume]] influences generated code.
- Cautionary note on the potential for [[assume]] to lead to undefined behavior.
Made with HARPA AI
Noreturn and void are redudant?
No, void just means there's no _return value_. [[noreturn]] means the function will not return control flow to the caller.
He was a bit unclear at that part. Any code you write after calling a noreturn function is considered to be dead code because that function will not be left through a return, only through a long jump or through exiting the program. With void everything you write after the function call just gets executed after the function returns.
When will C++ have built in support for networking?
C++26
Last time I checked, if I remember correctly, it was meant to be implemented with the new concepts of senders/receivers. They didn't want to just make another wrapper over OS sockets. It'll probably take a while (hopefully C++26, but who knows...). But it'll not happen until the senders/receivers and/or a proper asynchronous API/*the* async API is done. Look into P2300 proposal.
I would just use ASIO today if you really want networking. Whatever version gets included in C++ will end up out of date quickly as it can only be fixed / updated every 3 years.