Linguistically this doesn't make much sense. This layer doesn't sit between serialization formats. I'd say "abstraction layer for serialization formats".

supports

oeps

Using uint64_t is error-prone for a type named IntValue with eValueType::Int.

https://stackoverflow.com/a/13502497 suggests that JavaScript numbers roughly have a range of ±2**53, so int64_t will be sufficient.

Any reason to use float instead of double for JSON? This should be documented.

Why are std::shared_ptrs used here?

Something as abstractly named as "Value" really needs documentation as to what it is and what it's for.

Either add explicit or document why this constructor should not be explicit.

I feel that these should get some documentation as to what they return, and in which scope they're valid. Is the code expected to check the type, before calling any of these? Who owns the returned pointer?

These need documentation. What they do, but also what happens when the Value is not of the required type. Does that raise an exception? Return nulltpr? Produce invalid results?

Documentation, certainly about the template variables. It also needs to explain what "primitive" means; after all, eValueType is not named ePrimitiveValueType, so there must be some value types that you cannot use here.

be

key-value

Why is this a std::shared_ptr? Who owns the values? Who is expected to be sharing the values?

Document

Why does the value need to be mutable in order to serialize it? What modifications will this function do? Either make it const, or use a pointer so that at the call itself it's clear that the function can modify the value.

Document

Unless the full 0-255 range is needed, use int8_t instead. It'll give much more sensible erroneous results when there is some off-by-one error somewhere; invalid negative values can be tested for, but invalid wrapped-around-so-still-valid values cannot.

This assumes that any Value with type_ == eValueType::String is a StringValue. This tight coupling is not documented at all!

These should be extracted to their own functions.

Why is this necessary at all?

What is this notation?

Such blocks should be their own function

Then why are they (and this code) even here?

Also test with bigger & negative integers!

The type is called FloatValue but you test with a double literal. Be sure to actually test the precision by which these are saved, if you want to actually test doubles.

Shouldn't this be \see?

Document here, as people start reading from the top.

Remove "Helper function to"

Remove "Helper class for"

Instead of "internal" I'd call it "wrapped"; "internal" to me sounds too much like it's an implementation detail, but it's also part of the public interface of the type.

This function should be named value() (so it's consistent with IntValue::value()) and not string_value(). Otherwise it's unclear when you see an invocation like this:

j = value.as_string_value()->string_value();

as_string_value() already returns a "string value", so it's not immediately clear what different kind of "string value" would be returned by string_value().

will → would

will → would

I would add a bit more explanation on the very basics of the design. Mention how this can be used by other formats (by implementing a custom formatter using Formatter as base class), how data is modeled (what kind of primitives are supported and how ObjectValue can be used), is the order of items preserved when writing back to disk, how is versioning handled, etc.

If it becomes more than a few lines then it can just become a link to the Wiki.

Better default-initialize primitive values:

T inner_value_{};

Otherwise on a default construction for example, this would be uninitialized.

Think this should be explicit.

Very minor suggestion: I prefer using the single line syntax for such short doxygen comments:

/** Short description, blah blah. */

This seems a bit odd to me. I would expect the object to store items in a map itself, and a simple lookup function on the object directly. What's the reason for not doing this, to preserve the order of items? Is it really that important to preserve the order? If so, we could also store an index somehow and sort before writing. E.g. the object's map could be stored as Map<std::string, std::pair<std::unique_ptr<Value>, int>> -- maybe that makes internals more complex than they need to be, but at least the public API makes more sense to me.

Not against the current solution, just bringing up an alternative for consideration.