Add serialization

[yuvalif]

Adding circular buffer serialization (including the space optimized version). This is to address issue #24.
For performance reasons the serialization of the buffer itself is done in, bulk, in binary format, and not element by element.

[jeking3]

Licensing issues...

[jeking3]

This doesn't match the others - is it correct?

[yuvalif]

you mean the library location? i don't know why it is different, but this is the correct one for serialization

[glenfe]

This would make circular_buffer have a dependency on serialization which I'm not sure we want.

[jeking3]

It would be easy enough to include macro guards to disable it entirely if someone so desired...

[yuvalif]

@glenfe @jeking3 , in multi_index it was done under: BOOST_MULTI_INDEX_DISABLE_SERIALIZATION
will follow the same pattern here

[pdimov]

The tests only test a completely full buffer consisting of one span. In general, an archive does not allow two save_binary calls on save to be loaded with one load_binary.

Using binary serialization is questionable anyway. This only works for trivially copyable types, and the code doesn't check that; and text/xml archives are supposed to be portable, and dumping binary into them defeats their purpose. This implementation is only suitable for use with the nonportable binary archive.

[yuvalif]

@pdimov

The tests only test a completely full buffer consisting of one span.

Fragmented buffer was tested in the examples, will add to the unit test.

In general, an archive does not allow two save_binary calls on save to be loaded with one load_binary.

Didn't want to use serialize,to avoid changes to the buffer. Can change to 2 separate calls of load_binary. BTW, why is there an issue with 2 calls?

In general binary serialization was used for performance reasons, but I do see the issues with it. Will modify the implementation archive the elements one by one.

There is probably a way to specialize for the case that the archive is binary anyway - will look into that.

[pdimov]

BTW, why is there an issue with 2 calls?

Well, suppose that some XML archive implements save_binary as <binary>04A3719F...</binary>. The two save_binary calls will emit two such sequences. Then the load_binary call will only load the first one, and it won't have enough data inside.

[yuvalif]

• added disabling macro: BOOST_CIRCULAR_BUFFER_DISABLE_SERIALIZATION for the feature. @glenfe @jeking3 does it needs to be documented somewhere?
• added test for non-linearized buffer (which actually found a bug...)
• basic implementation serialize the elements one by one, added specialized implementation for the binary archive case. @pdimov please let me know if you still see issue with this optimization - if this is becoming too complex I can remove (note that there is a big difference in performance, shown in the example)
• note that XML archive is not supported, as I don't use NVP serialization. Don't think this is mandatory in the circular buffer case. And could be added later

[jeking3]

Documentation is useful, so if you can add it to the docs (BOOST_CIRCULAR_BUFFER_DISABLE_SERIALIZATION), I think that's best.