std::atomic_ref::fetch_add(3)

🎀 std::atomic_ref::fetch_add — C++ Standard Libary, section 3 💅

🌸 NAME 🌸

std::atomic_ref::fetch_add — std::atomic_ref::fetch_add

Yes bestie, the name is literally the same on both sides. It’s giving mirror selfie energy 💖.

---

✨ Synopsis ✨

okay so here’s the signature situation, and every line matters:

          member only of atomic_ref<Integral> and atomic_ref<Floating>
          template specializations
          T fetch_add( T arg,
                       std::memory_order order = std::memory_order_seq_cst )
       (1) (since C++20)
          const noexcept;
          member only of atomic_ref<T*> template specialization
          T* fetch_add( std::ptrdiff_t arg,
                        std::memory_order order = std::memory_order_seq_cst
       (2) (since C++20)
          ) const noexcept;

No cap: overload (1) is only for the atomic_ref<Integral> and atomic_ref<Floating> specializations, and overload (2) is only for the atomic_ref<T*> specialization. Both are (since C++20) and both are const noexcept era. Periodt ✨.

---

🧮 Parameters 🧮

• arg — the other argument of arithmetic addition. It’s the little number/pointer-ish bestie getting added in 🫶.
• order — memory order constraints to enforce. This is the vibe check for memory ordering 💅.

---

💖 Return value 💖

The value of the referenced object, immediately preceding the effects of this function. Like, the old value right before the add did its main character thing 💖.

---

🧪 Example 🧪

This section is incomplete 😭.

Reason: no example.

bestie, the manpage really said “no example” and dipped 🙈.

---

🗂️ Category 🗂️

• Todo no example

---

okay so what does this function actually do? It atomically replaces the current value of the referenced object with the result of arithmetic addition of the value and arg. This operation is a read-modify-write operation, no cap 🔥. Memory is affected according to the value of order ✨.

For signed integral types, arithmetic is defined to use two’s complement representation. There are no undefined results. Slay, no undefined-result jumpscare here 💀.

For floating-point types, the floating-point environment in effect may be different from the calling thread's floating-point environment. The operation need not be conform to the corresponding std::numeric_limits traits but is encouraged to do so. If the result is not a representable value for its type, the result is unspecified but the operation otherwise has no undefined behavior 🫶.

For T* types, the result may be an undefined address, but the operation otherwise has no undefined behavior. The program is ill-formed if T is not an object type. That’s the serious caveat, bestie — do not skip it 💅.

---

okay bye bestie, this page came from http://cppreference.com, dated 2024.06.10, and it’s the std::atomic_ref::fetch_add(3) page 💜🫶✨