Support std::atomic<T> fields

[RampantDespair]

Summary
Add native support for reflecting and (de)serializing std::atomic<T> fields, where T is already supported by reflect-cpp.

Motivation
In modern C++ codebases, std::atomic<T> is commonly used for counters, state flags, and progress indicators that still need to be reflected (e.g. JSON serialization, config snapshots, telemetry, IPC payloads).
Currently, structs containing std::atomic<T> fields are not reflectable without custom wrappers or manual conversion.

Proposed Behavior

• Treat std::atomic<T> as reflectable when T is reflectable.
• Serialization should read via load(std::memory_order_relaxed).
• Deserialization should write via store(value, std::memory_order_relaxed).
• No additional synchronization guarantees beyond atomicity are required.

Example

struct Stats {
    std::atomic<std::uint64_t> bytes_downloaded;
    std::atomic<bool>          finished;
};

Expected behavior:

• bytes_downloaded and finished serialize as their underlying values.
• Deserialization updates the atomics via store.

Notes

• This mirrors how many serialization libraries treat atomics (as value wrappers).
• Memory ordering can be relaxed, as reflection is value-oriented, not synchronization-oriented.

[liuzicheng1987]

Good idea. Easy to do and would be an improvement.

[liuzicheng1987]

@RampantDespair , turns out this is a but trickier than I originally assumed. What I didn't think of is the fact that atomic variables cannot be copied or moved. So something like this cannot work:

struct Stats {
    std::atomic<std::uint64_t> bytes_downloaded;
    std::atomic<bool> finished;
};

auto stats = rfl::json::read<Stats>(json_string);

The problem here is that we are need to copy or move the struct in the last line.

The best solution I can think of is something like this:

struct Stats {
    std::atomic<std::uint64_t> bytes_downloaded;
    std::atomic<bool> finished;
};

auto stats_wrapped = rfl::json::read<rfl::AtomicWrapper<Stats>>(json_string).value();

Stats stats;
stats_wrapped.assign(&stats);

Alternatively, it would be incumbent upon the user to define the move constructor:

struct Stats {
  std::atomic<std::uint64_t> bytes_downloaded;
  std::atomic<bool> finished;

  Stats(Stats&& other) noexcept
      : bytes_downloaded(
            other.bytes_downloaded.load(std::memory_order_relaxed)),
        finished(other.finished.load(std::memory_order_relaxed)) {}

  Stats& operator=(Stats&& other) noexcept {
    bytes_downloaded.store(
        other.bytes_downloaded.load(std::memory_order_relaxed),
        std::memory_order_relaxed);
    finished.store(other.finished.load(std::memory_order_relaxed),
                   std::memory_order_relaxed);
    return *this;
  }

  Stats(const std::uint64_t _bytes_downloaded, const bool _finished)
      : bytes_downloaded(_bytes_downloaded), finished(_finished) {}
};

[liuzicheng1987]

@RampantDespair , what are your thoughts on this?

[RampantDespair]

@liuzicheng1987

That sounds absolutely reasonable to me 👍

Given the constraints around std::atomic not being copyable/movable, I don’t really see a better general solution unless the move/copy constructors can be auto-generated by the library itself (e.g. via reflection-aware synthesis).

The wrapper approach makes the semantics explicit and avoids forcing users to write boilerplate unless they want a more ergonomic type. I’m perfectly fine with that trade-off.

[liuzicheng1987]

@RampantDespair , it's not quite ready for prime time, but this PR resolves the issue:

#577

There are now two possibilities to handle this, both of which are more elegant than the wrapper:

struct Stats {
  std::atomic<std::uint64_t> bytes_downloaded;
  std::atomic<bool> finished;
};

 Stats stats{};

 const rfl::Result<rfl::Nothing> res =
      rfl::json::read<rfl::atomic::remove_atomic_t<Stats>>(json_str).transform(
          [&](auto&& t) {
            return rfl::atomic::set_atomic(std::move(t), &stats);
          });

if(!res) {
    std::cout << "Error parsing Stats: " << res.error().what() << std::endl;
}

The other possibility is to wrap Stats in std::shared_ptr, std::unique_ptr, rfl::Ref, or rfl::Box:

const auto stats = rfl::json::read<std::shared_ptr<Stats>>(json_str);

What are your thoughts?

[RampantDespair]

@liuzicheng1987

Thanks for the update!

One small clarification: from my perspective it doesn’t matter how it’s done internally, as long as the final logic actually does atomic loads when reading and atomic stores when writing the std::atomic fields (e.g., via load()/store() with the appropriate memory ordering), that’s what I care about for ergonomics and safety.

So the answer is basically either approach is fine as long as the end result uses atomic load/store under the hood, that’s what preserves the intended behavior for reflecting atomics in and out of JSON.

[liuzicheng1987]

@RampantDespair, yes, it certainly does that. You can take a look at include/rfl/atomic/is_atomic.hpp:

template <class T>
struct is_atomic<std::atomic<T>> {
  static constexpr bool value = true;
  using RemoveAtomicT = T;
  static void set(RemoveAtomicT&& val, std::atomic<T>* _t) {
    _t->store(std::forward<RemoveAtomicT>(val), std::memory_order_relaxed);
  };
};

And the same is happening for load as well.

[RampantDespair]

Amazing and fast work as always!
Thanks for the clarification and for taking care of the atomic load/store semantics so thoroughly, really appreciate it!
Do you have any idea when this change (or a release including it) might be published as a version on vcpkg?

[liuzicheng1987]

@RampantDespair I will certainly be able to merge into main within the next couple of days.

We can basically do a release whenever we want to...is this something you urgently need?

[RampantDespair]

@liuzicheng1987

It would be helpful to get a release on vcpkg sooner rather than later if possible, but it’s not catastrophic if it needs to wait a bit. I’m happy to work with whatever timeline makes the most sense for you.