On 2014-02-13 23:56, Orvid King wrote:
Well, I wrote the code for this a while back, and although it was
originally intended as a replacement for just std.json (thus the repo
name), it does have the framework in place to be a generalized
serialization framework, and there is the start of xml, and bson
implementations, so I'm releasing it as std.serialization. The JSON
implementation is the only one I'd consider ready for production use
however. The (de)serialization framework takes a step back and asks,
"Why do we need pull parsers?", the answer to which is that allocations
are slow, so don't allocate. And that's exactly what I do. The
serializer does absolutely *no* allocations of it's own (except for
float->string conversion, which I don't understand the algorithms enough
to implement myself) even going so far as to create an output range
based version of to!string(int/uint/long/ulong/etc.). And the benefits
of doing it this way are very clearly reflected in the pure speed of the
serializer. On my 2ghz i5 Macbook Air, it takes 50ms to serialize 100k
objects with roughly 600k integers contained in them when compiled with
DMD, this roughly half the time it takes to generate the data to
serialize. Compile it with GDC or LDC and that time is cut in half. I
have done the exact same thing with deserialization as well, the only
allocations done are for the output objects, because there is no
intermediate representation.
What features does it support? How does it handle:
* Arrays
* Slices
* Pointers
* Reference types
* Support for events
* Custom serialization
* Serialization of third party types
So how do I use this greatness? Simple! import std.serialization, and
apply the @serializable UDA to the class/struct you want to serialize,
then call toJOSN(yourObject) and fromJSON!YourType(yourString) to your
heart's content!
Why require a UDA?
Now, there are other serialization libraries out there, such as orange,
that take the compile-time reflection approach, but the amount of code
required to implement a single format is just massive 2100 lines for the
XMLArchive. The entire JSON (de)serialization, which *includes* both the
lexer and parser is only 900 lines.
The reason for that might be:
1. XML is untyped unlike JSON
2. It supports quite a lot of features that most other serialization
libraries don't support
--
/Jacob Carlborg
