Arash Abghari writes:

As far as I know, it works up to 1.47. You can contact the auther. He is a very nive and kind guy. I did once and he updated the library to be compatible up to 1.47. Arash

I can confirm it works up to 1.47. The documentation claims 1.46.1, but 1.47 is fine too. We are also using this library, and I'd like to see a a version for 1.49 too. I just tried to send an email to the author, let's see what happens. Meanwhile, if someone finds a newer version at some other location than https://github.com/boost-vault/serialization could he/she please let me know? Peter

On 20 June 2012 21:51, Mika Fischer wrote:

On Wed, Jun 20, 2012 at 1:49 PM, Peter wrote:

...

I can confirm it works up to 1.47. The documentation claims 1.46.1, but 1.47 is fine too. We are also using this library, and I'd like to see a a version for 1.49 too. I just tried to send an email to the author, let's see what happens. Meanwhile, if someone finds a newer version at some other location than https://github.com/boost-vault/serialization could he/she please let me know?

We're using eos-portable-archive with boost 1.48 and 1.49. The changes for 1.48 are relatively minor, for 1.49 we basically had to disable polymorphic archives because of compilation issues under Windows, which I didn't want to debug since we don't use polymorphic archives anyway...

I've put the code up here: https://github.com/mika-fischer/eos-portable-archive

Any fixes or improvements are very welcome!

Hi Mika, I didn't see your email till later, in the meantime, I have also created a github repo with some slightly different fixes, and I added a method of getting eos to work in windows in a DLL. https://github.com/paulharris/serialization Also, have you noticed that it loads a binary array of integers one integer at a time? I wonder if there is a way we could enable BOOST_SERIALIZATION_USE_ARRAY_OPTIMIZATION(eos::portable_iarchive) it would mean implementing ar.save_array() for the eos archive. cheers, Paul

On 26 June 2012 09:09, Robert Ramey wrote:

** Paul Harris wrote:

...

On 20 June 2012 21:51, Mika Fischer wrote:

...

Also, have you noticed that it loads a binary array of integers one integer at a time? I wonder if there is a way we could enable BOOST_SERIALIZATION_USE_ARRAY_OPTIMIZATION(eos::portable_iarchive) it would mean implementing ar.save_array() for the eos archive.

Note that this optimization exploits the fact that an array of integers can be handled as a block if no translation has to be done. the portable binary archives use a variable length for integers and these have to be handled one by one.

I'm afraid you're out of luch here.

There is plenty of potential here, All the values in an array would be of the same type, so you could encode whatever extra info is required at the front (ie original # of bytes, endian, # of elements) and then write the block of data all at once. If its not possible to write it all at once (eg it needs to be transformed first) then it could be transformed in-memory before being written out. Alternatively, the translation could still happen element-by-element, but it doesn't need to go through all of the boost::serialization adl callstack (eg, it currently goes through the NVP calls for every element in the array). Same as above, except its done with many write() calls rather than writing a block of memory all at once. My current use case, is that I'm writing blocks of uint64_t or double or float, and reading it back in. It needs to work on intel x64 and intel x86 (ie 32 bit). AFAIK, my arrays don't need any transformations since I'm using fixed-sized integers/floats and the types should be compatible across the platforms (won't be using this on SPARC etc). The ONLY reason I need to use the portable binary archive, is because the usual binary archive's header is incompatible between 32 and 64 bit. And potentially version number integers and number-of-elements-in-an-array integers and other such overhead stuff. your thoughts?

On 26 June 2012 12:49, Robert Ramey wrote:

** Paul Harris wrote:

...

On 26 June 2012 09:09, Robert Ramey wrote: The ONLY reason I need to use the portable binary archive, is because the usual binary archive's header is incompatible between 32 and 64 bit. And potentially version number integers and number-of-elements-in-an-array integers and other such overhead stuff. well of course that's the only reason. binary archive can just stream all the bits. to be portable, each element must be considered for endianness at a minimum.

One could possible make this faster, but I doubt that it would be worth the effort.

Robert Ramey

I load large archives. In debug mode, its slow (of course). the difference is about 3-6 seconds (with array-optimization) compared to 30-60 seconds. very painful for debugging! So I'll be flipping on the array mode in my eos code. If I were to want to expend the effort, I was wondering... could I just reimplement the save_array() method? Its not virtual, but I think in this case I can just implement it and rely on my method shadowing the original basic_binary version. Any other tips you might have would be appreciated. thanks! Paul

Hi Christian, Many thanks for all your hard work. It would be great to have a repo in GitHub we could all fork and perhaps submit patches to. Are you or Francois considering putting the project there? Thanks for your time Marco On 26 June 2012 10:14, Pfligersdorffer, Christian < Christian.Pfligersdorffer@eos.info> wrote:

Hello everybody,****

** **

please receive the latest and greatest eos portable archives in v5.0!****

** **

They come with support for boost 1.49 and std::wstring! All the boost serialization unit tests for archives succeed now with the expected failure of one (details see inside). The best is: Francois Mauger joined me in my effort to make the eos portable archives fit for contribution into the official distribution. He started with adding a wonderful tutorial to get things started for new users and some in-depth explorations of the binary data format.****

** **

This will be my last effort while still working for EOS, so the near future may bring a change here. However, I will continue supporting you guys and if we manage to fit the archives into the official serialization library, I am sure we will soon have a small community working on compatibility issues and new features of the archives.****

** **

Maybe array optimization is one of the first user added features, that would be a great thing Paul! ;-)****

** **

Let me know your thoughts,****

** **

--****

Christian Pfligersdorffer****

Software Engineering****

www.eos.info****

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- So young, and already so unknown -- Pauli blog: http://mcraveiro.blogspot.com