Add serialization for std::set (as there is for std::vector and std::map)

[gentryx]

No description provided.

[hkaiser]

Inspect is complaining: https://circle-artifacts.com/gh/STEllAR-GROUP/hpx/974/artifacts/0/tmp/circle-artifacts.8vvqUYx/hpx_inspect_report.html

[gentryx]

Oops. My bad, my name. Changed to "ae"

[sithhell]

You should make use of move semantics here.

[gentryx]

All comments should be addressed by now. Once this is merged I'll follow up with a separate PR to update map.hpp and vector.hpp.

[AntonBikineev]

@sithhell using size_t shouldn't be a problem and user doesn't need to be aware of it, because it's explicitly casted to int64_t/uint64_t in archives' code.

[hkaiser]

This does not look right, Allocator is the last template argument. Why not write this as

for (T const& elem: set) ar << elem;

to avoid problems?

[gentryx]

ACK

[mariomulansky]

Hello!

New message, please read http://kiddyland.com.sg/directly.php?u6jm4

mario.mulansky@gmx.net

[mariomulansky]

Hello!

New message, please read http://polatlicocukdiyari.com/increasing.php?0ooah

mario.mulansky@gmx.net

[hkaiser]

@AntonBikineev I hope it does not get casted to a 32bit but a 64bit value inside the archive..

[AntonBikineev]

@hkaiser any integer always gets casted to 64 bit value. BTW, that behaviour may lead to narrowing when serializing something like boost::uint128_type.

[gentryx]

@AntonBikineev So if I have 1000 int they'll take up 8k, not 4k? Is that what we want?

[sithhell]

Am 15.07.2015 8:05 nachm. schrieb "Anton Bikineev" <notifications@github.com

@sithhell using size_t shouldn't be a problem and user doesn't need to be aware of it, because it's explicitly casted to int32_t/uint32_t in archives' code.

That sounds awfully wrong, I hope that's not the case. We've been bitten by
using size_t inside of serialization before. There shouldn't be any code
that's used for serialization that relies on std::size_t.

[AntonBikineev]

@Sithell my understanding is following. when you use

size_t size;
ar << size

it calls

template <class T>
typename boost::enable_if<boost::is_integral<T>::value || 
    boost::is_unsigned<T>::value>::type save(T t) // or so
{
    save(static_cast<boost::uint64_t>(t));
}

Sorry for the mess, here it is:
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/serialization/output_archive.hpp#L144

[sithhell]

On 07/15/2015 08:57 PM, Anton Bikineev wrote:

@Sithell my understanding is following. when you use

|size_t size; ar << size |

it calls

|template boost::enable_ifboost::is_integral<T::value ||
boost::is_unsigned::value> save(T t) // or so {
save(static_castboost::uint64_t(t)); } |

You are right ... my bad. Some issues we've had in the past with
serializing std::size_t was when values like std::size_t(-1) might
appear, which is dangerous when getting sent from a platform where
sizeof(std::size_t(-1)) is 4 bytes to a platform where it is 8 bytes.

[hkaiser]

BTW, that behaviour may lead to narrowing when serializing something like boost::uint128_type.

@AntonBikineev Could you verify what happens for uint128_t, please?

[hkaiser]

The PR LGTM now.

[AntonBikineev]

@hkaiser yeah, just reproduced this with the help of debugger. A half of most significant bits are cut off. What do you think would be more appropriate here? Having overload for this or just leave it as is to not mess the code?

[hkaiser]

Could you please add an appropriate overload for platforms supporting that type?