Boost::UUID setting specific value

Question

In Java UUID Class there is a way to set upper and lower longs to create a specific value for UUID.

UUID test(-1, -1);

will generate UUID: ffffffff-ffff-ffff-ffff-ffffffffffff

Is there a similar method to create one with BOOST UUID in C++ other then creating a string version of it and converting it back to UUID?

Are you referring to setting each of the 16 bytes to -1? What if the values is not specifically all 0xff? — Karlson, Mar 31 '20 at 19:53
I'm not referring to anything, I'm asking whether you have consulted the documentation. Presumably the features available are listed in that. Do you think there is something missing from it? — Asteroids With Wings, Mar 31 '20 at 20:01
There are 2 methods that are being described there. 1. Convert from String, 2. Set each of the 16 bytes individually. Neither one of these is ideal. That's why Java's version of setting 2 long values is so advantageous — Karlson, Mar 31 '20 at 20:08
I have considered it. But that copying needs to be very careful because of big vs. Little endian — Karlson, Mar 31 '20 at 20:12
That is true (though trivial). Anyway I realised that there is no generator to do that, only a way to _get_ the bytes making up a UUID you already composed. — Asteroids With Wings, Mar 31 '20 at 20:13
FWIW, by sheer co-incidence, I implemented my own UUID type just last week and it takes (via a `private` ctor and a friend) two `uint64_t`s because, I agree, it's useful. — Asteroids With Wings, Mar 31 '20 at 20:14
[There's no issue open for this on GitHub yet](https://github.com/boostorg/uuid). You could post one and see what the devs think. — Asteroids With Wings, Mar 31 '20 at 20:16

score -1 · Answer 1 · answered Apr 01 '20 at 09:20

-1

Passing integers to constructor would be ambiguous because you don't know what UUID they would generate as integers can have different byte representations on different platforms. Sure, all-ones (as in -1) and all-zeros make it more or less obvious, but what about other integer values?

The solution is either construct UUID from string or from bytes.

boost::uuids::uuid u1{{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }};

boost::uuids::uuid u2 = boost::uuids::string_generator()("ffffffff-ffff-ffff-ffff-ffffffffffff");

std::istringstream strm("ffffffff-ffff-ffff-ffff-ffffffffffff");
boost::uuids::uuid u3;
strm >> u3;

answered Apr 01 '20 at 09:20

Andrey Semashev

10,046
1
17
27

I would have to downvote specifically about the byte representations. This has been a known problem between different architectures for decades that's why htonl/ntohl and similar functions exist currently as part of the socket communications but it doesn't mean that they cannot be migrated out. – Karlson Apr 01 '20 at 17:29
Not sure what is your complaint regarding the answer. Endian conversion routines exist, but it doesn't make them a suitable tool for UUID construction. I bet you 95% of users will not call endian conversion functions when initializing a UUID. – Andrey Semashev Apr 01 '20 at 18:43
Complaint is very simple. The user should not calling for endian conversion prior to invoking uuid constructor. If this is an issue it should be addressed by the constructor code itself. So your point on not knowing what UUID will be constructed from the integers or rather 64-bit integers due to endianness of the internal representation is not valid. – Karlson Apr 01 '20 at 18:56
The only issue here and this is where the answer lies in the current version of the boost::uuid is that outside of string or random generation the only way to construct it is with a list of byte values, which is annoying as hell. – Karlson Apr 01 '20 at 18:57
@Karlson Having UUID constructor convert endianness is counter-intuitive as well, as this is not the normal behavior for other types. This is why I'm saying this would be confusing to users - either the internal behavior of the constructor is not obvious, or the user has to make effort to provide input in a very specific, error-prone, possibly not portable way. Note that RFC4122, which Boost.UUID implements, does not define UUID as a pair of 64-bit integers. If you have to construct UUIDs this way, I suspect you're probably doing something wrong. – Andrey Semashev Apr 01 '20 at 19:49
I am not sure I follow. The RFC specifies the allocation of bits during random generation. Initialization from a byte array basically is a non-random UUID. Using 64-bit integers instead of bytes doesn't lend itself to fast construction like using `memcpy` but it is basically same thing semantically and endianness is not a big enough deal to work with to be considered a showstopper. – Karlson Apr 01 '20 at 21:01
@Karlson Obviously, we disagree on the endianness part. Regarding UUID structure, it is defined in https://tools.ietf.org/html/rfc4122#section-4.1.2. So UUID is a structure of several fields, with certain requirements on the values of these fields. You can also treat the whole UUID as a 16-byte blob, of course. The point is that two 64-bit integers do not match that structure. And because of the endianness issue, they also are a poor way to represent the 16-byte blob. So constructing a UUID from two integers makes no sense. – Andrey Semashev Apr 01 '20 at 23:13
My point is that endianness is not an issue in constructing an unstructured blob it is not as simple as from a byte array but it is not generally an issue. Constructing a UUID as an unstructured blob is not an ideal way to use UUID but sometimes it is better then the alternative. – Karlson Apr 02 '20 at 01:14

Boost::UUID setting specific value

1 Answers1