C++ Weekly - Ep 423 - Complete Guide to Attributes Through C++23
Вставка
- Опубліковано 8 чер 2024
- ☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟
Upcoming Workshop: Understanding Object Lifetime, C++ On Sea, July 2, 2024
► cpponsea.uk/2024/sessions/und...
Upcoming Workshop: C++ Best Practices, NDC TechTown, Sept 9-10, 2024
► ndctechtown.com/workshops/c-b...
This episode is sponsored by think-cell. think-cell.com/cppweekly
Episode details: github.com/lefticus/cpp_weekl...
T-SHIRTS AVAILABLE!
► The best C++ T-Shirts anywhere! my-store-d16a2f.creator-sprin...
WANT MORE JASON?
► My Training Classes: emptycrate.com/training.html
► Follow me on twitter: / lefticus
SUPPORT THE CHANNEL
► Patreon: / lefticus
► Github Sponsors: github.com/sponsors/lefticus
► Paypal Donation: www.paypal.com/donate/?hosted...
GET INVOLVED
► Video Idea List: github.com/lefticus/cpp_weekl...
JASON'S BOOKS
► C++23 Best Practices
Leanpub Ebook: leanpub.com/cpp23_best_practi...
► C++ Best Practices
Amazon Paperback: amzn.to/3wpAU3Z
Leanpub Ebook: leanpub.com/cppbestpractices
JASON'S PUZZLE BOOKS
► Object Lifetime Puzzlers Book 1
Amazon Paperback: amzn.to/3g6Ervj
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Object Lifetime Puzzlers Book 2
Amazon Paperback: amzn.to/3whdUDU
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Object Lifetime Puzzlers Book 3
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Copy and Reference Puzzlers Book 1
Amazon Paperback: amzn.to/3g7ZVb9
Leanpub Ebook: leanpub.com/copyandreferencep...
► Copy and Reference Puzzlers Book 2
Amazon Paperback: amzn.to/3X1LOIx
Leanpub Ebook: leanpub.com/copyandreferencep...
► Copy and Reference Puzzlers Book 3
Leanpub Ebook: leanpub.com/copyandreferencep...
► OpCode Puzzlers Book 1
Amazon Paperback: amzn.to/3KCNJg6
Leanpub Ebook: leanpub.com/opcodepuzzlers_book1
RECOMMENDED BOOKS
► Bjarne Stroustrup's A Tour of C++ (now with C++20/23!): amzn.to/3X4Wypr
AWESOME PROJECTS
► The C++ Starter Project - Gets you started with Best Practices Quickly - github.com/cpp-best-practices...
► C++ Best Practices Forkable Coding Standards - github.com/cpp-best-practices...
O'Reilly VIDEOS
► Inheritance and Polymorphism in C++ - www.oreilly.com/library/view/...
► Learning C++ Best Practices - www.oreilly.com/library/view/... - Наука та технологія
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.
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
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.
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.
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.
🎯 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