std.serialization

[Rory McGuire]

Nice, hope the code is prettier than your speech. :D


On Fri, Feb 14, 2014 at 12:56 AM, Orvid King <blah38621 at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20140214/8ed0a8ce/attachment-0001.html>