Forum Replies Created
-
AuthorPosts
-
12. May 2025 at 19:17 in reply to: Behaviour of global static, thread-local, atomic variables in multi-threading #638301::
Before I answer the question, I have two general comments.
- It is usually not a good idea to work directly on a shared variable. It is often a good idea to use a local variable. Only the update of the shared variable with the local variable needs to be protected.
- If a shared variable is initialized, this should be done before threads are started. In this case, shared variables do not need to be protected.
static variables could be victims of data races, as they are only fully initialized at program runtime.(static)
thread_local guarantees that each thread that uses this variable receives its own copy of it.(Thread-local data)
atomic variables have major restrictions. Essentially, only integral data can be atomic. With C++20 this is still possible for floating point numbers. User-defined data can also be atomic if it is sufficiently simple.(atomic)
8. April 2025 at 16:58 in reply to: C.81: Use =delete when you want to disable default behavior – Use Case #63814723. March 2025 at 21:59 in reply to: Implement an asynchronous and interruptible iterative solver with concurrency #637975::Your data is probably on the same cache line. One cache line invalidates the other. More about cache lines: std::array and std::vector are your Friends.
23. March 2025 at 20:57 in reply to: Practice on STL sorting of strings comparing performance #637972::Performance tests without maximized optimization make no sense: https://godbolt.org/z/vjsdMxcKo. Additionally, you can sort in parallel.
::This is precisely how function template type deduction works (Template Arguments), which is called decay.
14. March 2025 at 12:00 in reply to: Missing Article Links in Week 3 – Lvalue and Rvalue References and Casts #637817::In addition, you can link in C++23 operations on std::optional or std::expected. See: C++23: A New Way of Error Handling with std::expected
::Here is Andreas Fertig answer:
I don’t know what exactly the reason is, but I know the reasons for the second variant. The alignas only applies to the one variable at the top, foo. However, it can easily be passed to a function, for example, and the alignment is ignored: https://compiler-explorer.com/z/8K9Kds519.
The same applies to assignments to a suitably sized std::byte. This can have a different alignment.
With the storage variant, the alignment of foo is preserved, provided that the complete structure is passed to a function. I strongly suspect that this is also their motivation.
::You should use a std::vector if the container is to become larger at runtime or very large. std::array uses the stack, whereas std::vector uses the heap. The size of the stack is very limited.
With C++26 we get the std::inplace_vector. Its capacity is defined at compile time so that new elements can be added at runtime. std::inplace_vector is a drop-in replacement for std::vector.
std::vector and std::array could only be used in constant expressions.
-
AuthorPosts