Nice, hope the code is prettier than your speech. :D
On Fri, Feb 14, 2014 at 12:56 AM, Orvid King <[email protected]> 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. > > 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! > > 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. > > > > > Wow, that went a bit more towards a salesman-like description than I as > aiming for, so I'll just end this here and give you the link, before this > ends up looking like a massive, badly written, sales pitch :D > > https://github.com/Orvid/JSONSerialization >
