This adds a READWRITEAS(type, obj) macro which serializes obj as if it were converted to const type& when const, and to type& when non-const. No actual cast is involved, so this only works when this conversion can be done automatically.
This makes it usable in serialization code that uses a single implementation for both serialization and deserializing, which doesn't know the constness of the object involved.
This is a redo of #12712, using a slightly different interface.
147 | @@ -148,7 +148,14 @@ enum 148 | SER_GETHASH = (1 << 2), 149 | }; 150 | 151 | -#define READWRITE(...) (::SerReadWriteMany(s, ser_action, __VA_ARGS__)) 152 | +//! Convert the reference base type to X, without changing constness or reference type. 153 | +template<typename X> X& ReadWriteAsHelper(X& x) { return x; } 154 | +template<typename X> const X& ReadWriteAsHelper(const X& x) { return x; } 155 | +template<typename X> X&& ReadWriteAsHelper(X&& x) { return std::move(x); }
As x is X&&, is std::move necessary?
x is a variable, and thus can't be a temporary.
The type of the expression x is X. The X&& in the function signature makes that particular instance match cases where it's invoked with a temporary as argument, but once assigned to the variable x that is gone.
I think this may be broken in the case where x binds to the temporary result of an implicit conversion, e.g. in deserialization of ServiceFlags nServices above as int64_t, or in a more straightforward case of a char variable being deserialized as an int. In these cases the deserialization will just happen into a temporary variable, and the actual obj argument passed to READWRITEAS won't get updated.
This could be fixed with a serialization wrapper class that can deserialize into a temporary and then save the results on destruction. But a simpler alternative might just be to drop the two rvalue reference overloads of ReadWriteAsHelper so it would be an error to call READWRITEAS anywhere where deserialization would need to happen into a temporary variable. It seems like the only place where this happens is with nServices
This adds a READWRITEAS(type, obj) macro which serializes obj as if it
were casted to (const type&) when const, and to (type&) when non-const.
This makes it usable in serialization code that uses a single
implementation for both serialization and deserializing, which doesn't
know the constness of the object involved.
@ryanofsky Scary. I've removed the T&& overloads on the ReadWriteAsTypeHelper function, and will use a different approach for serializing ServiceFlags.
utACK 818dc74ba2745872fd68d2158380fc8bd331210e
utACK 818dc74ba2745872fd68d2158380fc8bd331210e. Only difference since last review is potentially dangerous rvalue overloads removed, and nServices change reverted.
utACK 818dc74ba2745872fd68d2158380fc8bd331210e