>
> Just have a class template with custom serialization and wrap fundamental
> types in it. This is what I do for MIDI variable
> length values and WebAssembly integers.


That leads to duplication, since you need to write custom read/write for
every type (and wrap each fundamental type in there).
In case you have codec concept you specify serialization for fundemantal
type in one place (in codec), and you don't need to write custom read/write
function for each user-defined type per custom codec.
I.e.
Your solution:
struct MyStruct { int a; int b;}
void writeMidiFile(const MyStruct& obj, output_stream& os)
{
  std::io::write(MidiInt(obj.a), os);
  std::io::write(MidiInt(obj.b), os);
}
and write such function for each and every user defined struct that you
want to serialize (for each serialization format).

Instead parametrize by codec:
void write(const MyStruct& obj, output_stream& os, Codec auto& cdc)
{
  std::io::write(cdc.encode(obj.a), os);
  std::io::write(cdc.encode(obj.b), os);
}
And you have only one 'write' function per user defined type, for all
serialization formats.

I will look into it when std::bit_cast and modules land. Only with those
> features in place we could get both compile time and
> run time benchmarks that are fair.
>

You don't need benchmarks to know that the less code the compiler needs to
parse, the faster the compilation.


pt., 6 mar 2020 o 13:01 Lyberta via Std-Proposals <
std-proposals_at_[hidden]> napisał(a):

> Maciej Cencora:
> > Even if compilers will optimize the code out, all users will have the pay
> > the cost of slower compilation (because compiler still needs to
> instantiate
> > the serialization code for big/little endian).
> > Basically with current design this is an early pessimization.
>
> I will look into it when std::bit_cast and modules land. Only with those
> features in place we could get both compile time and
> run time benchmarks that are fair.
>
> > You should focus on providing low-level primitives first.
> > Maybe something like Codec concept that allows serializing primitive
> types
> > (instead of enum format member in context concept), and provide two
> > implementations BigEndianCodec, LittleEndianCodec - and allow users to
> > provide custom ones.
>
> I would argue that primitive types + traits classes are violations of type
> system. I wanted to provide minimum default for the
> most basic case and then let users write strong types that do their own
> serialization.
>
> > With your current design I see no easy way to provide custom
> serialization
> > codec (e.g. Type-Length-Value).
>
> Just have a class template with custom serialization and wrap fundamental
> types in it. This is what I do for MIDI variable
> length values and WebAssembly integers.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>