> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > Sent: Wednesday, 16 August 2023 19.26 > > On Mon, Aug 14, 2023 at 05:13:04PM +0200, Morten Brørup wrote: > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > Sent: Monday, 14 August 2023 15.46 > > > > > > mercredi 9 août 2023, Morten Brørup: > > > > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > > > > Sent: Tuesday, 8 August 2023 22.50 > > > > > > > > > > On Tue, Aug 08, 2023 at 10:22:09PM +0200, Morten Brørup wrote:
[...] > > > > And what about C++ atomics... Do we want (or need?) a third > variant > > > using C++ atomics, e.g. "atomic<int> x;" instead of "_Atomic int > x;"? (I > > > hope not!) For reference, the "atomic_int" type is "_Atomic int" in > C, > > > but "std::atomic<int>" in C++. > > > > > > > > C++23 provides the C11 compatibility macro "_Atomic(T)", which > means > > > "_Atomic T" in C and "std::atomic<T>" in C++. Perhaps we can > somewhat > > > rely on this, and update our coding standards to require using e.g. > > > "_Atomic(int)" for atomic types, and disallow using "_Atomic int". > > > > > > You mean the syntax _Atomic(T) is working well in both C and C++? > > > > This syntax is API compatible across C11 and C++23, so it would work > with (C11 and C++23) applications building DPDK from scratch. > > > > But it is only "recommended" ABI compatible for compilers [1], so DPDK > in distros cannot rely on. > > > > [1]: https://www.open- > std.org/jtc1/sc22/wg21/docs/papers/2020/p0943r6.html > > > > It would be future-proofing for the benefit of C++23 based > applications... I was mainly mentioning it for completeness, now that we > are switching to a new standard for atomics. > > > > Realistically, considering that 1. such a coding standard (requiring > "_Atomic(T)" instead of "_Atomic T") would only be relevant for a 2023 > standard, and 2. that we are now upgrading to a standard from 2011, we > would probably have to wait for a very distant future (12 years?) before > C++ applications can reap the benefits of such a coding standard. > > Since writing the paragraph above a few day ago, I have become wiser today [1]... It turns out that the "_Atomic(T)" syntax not only comes really into play with C++23, but it is directly relevant for C11. Everyone, please pardon the confusion the above paragraph might have caused! [1]: http://inbox.dpdk.org/dev/98cbd80474fa8b44bf855df32c47dc35d87...@smartserver.smartshare.dk/ > > i just want to feedback on this coding convention topic here (in > relation to the RFC patch series thread) i think the convention of using > the macro should be adopted now. the main reason being that it is far > easier that an atomic type is a type or a pointer type when the '*' is > captured as a part of the macro parameter. > > please see the RFC patch thread for the details of how this was > beneficial for rcs_mcslock.h and how the placement of the _Atomic > keyword matters when applied to pointer types of incomplete types.
