[std-proposals] uuid again

[Tony V E]

I see the uuid proposal (wg21.link/p0959) is back, and might get looked at
next week in San Diego.

Questions:

0. will the author be present? (If not, would they like me to present it?)

1. The main question I still have is this idea of whether the internal byte
order is fixed, or implementation defined.
There are begin/end iterators, and they mention impl defined order, but
then there is also as_bytes, returning a span...
But that span is almost useless if the byte order is impl-defined, so I'm
confused.

The difference between fixed order and impl defined order comes down to, I
think, being able to use int compares (or even a 128bit int compare) vs
memcmp() when doing comparisons (for ordering at least - you could do
128bit == regardless of byte order). Is that the main difference?
(And faster compare comes at the cost of more expensive iteration, I think.)


2. why parse both "xxx...." and "{ xxx..... }" (and are spaces allowed
around the brackets?) - how about just specifying "xxx..." only?


3. what about an initializer_list constructor (can you check the length of
an initializer_list at compile time? probably not?) or actually a
constructor that takes 16 bytes?
All the examples construct arrays and spans, etc from { a, b, c, ... } but
you can't create a uuid directly from { a, b, c ... } ?

[Bryce Adelstein Lelbach aka wash]

Brief follow up - I asked Tony if he would be able to present this, if
the author is not present.

Marius - can you please include your email address in future revisions
of the paper? There needs to be some way to figure out how to contact
you from the proposal.

I see the uuid proposal (wg21.link/p0959) is back, and might get looked at next week in San Diego.
0. will the author be present? (If not, would they like me to present it?)
1. The main question I still have is this idea of whether the internal byte order is fixed, or implementation defined.
There are begin/end iterators, and they mention impl defined order, but then there is also as_bytes, returning a span...
But that span is almost useless if the byte order is impl-defined, so I'm confused.
The difference between fixed order and impl defined order comes down to, I think, being able to use int compares (or even a 128bit int compare) vs memcmp() when doing comparisons (for ordering at least - you could do 128bit == regardless of byte order). Is that the main difference?
(And faster compare comes at the cost of more expensive iteration, I think.)
2. why parse both "xxx...." and "{ xxx..... }" (and are spaces allowed around the brackets?) - how about just specifying "xxx..." only?
3. what about an initializer_list constructor (can you check the length of an initializer_list at compile time? probably not?) or actually a constructor that takes 16 bytes?
All the examples construct arrays and spans, etc from { a, b, c, ... } but you can't create a uuid directly from { a, b, c ... } ?
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbits_Afe5ONhBYRi2Nd0uhzyYp4rrDXPskn4VuwN4Rfw8g%40mail.gmail.com.

--
Bryce Adelstein Lelbach aka wash
ISO C++ Committee Member
HPX and Thrust Developer
CUDA Convert and Reformed AVX Junkie
--

[Corentin]

We can discuss more next week about this, but, having used both
boost::uuid and QUuid
recently, a few remarks

* There is a high enough chance that a string you get from some input not
in your control will have braces. Lots of people adopted the Microsoft
notation for some reason, and if std::uuid doesn't prepare for it, I
suspect people will have to check for braces virtually everywhere. So
thumbs up for handling that

* The span constructor is very useful if and only if the order is
determined (notably think deserialization from a binary stream of some
kind).


Corentin

Post by Tony V E
I see the uuid proposal (wg21.link/p0959) is back, and might get looked at
next week in San Diego.
0. will the author be present? (If not, would they like me to present it?)
1. The main question I still have is this idea of whether the internal
byte order is fixed, or implementation defined.
There are begin/end iterators, and they mention impl defined order, but
then there is also as_bytes, returning a span...
But that span is almost useless if the byte order is impl-defined, so I'm
confused.
The difference between fixed order and impl defined order comes down to, I
think, being able to use int compares (or even a 128bit int compare) vs
memcmp() when doing comparisons (for ordering at least - you could do
128bit == regardless of byte order). Is that the main difference?
(And faster compare comes at the cost of more expensive iteration, I think.)
2. why parse both "xxx...." and "{ xxx..... }" (and are spaces allowed
around the brackets?) - how about just specifying "xxx..." only?
3. what about an initializer_list constructor (can you check the length of
an initializer_list at compile time? probably not?) or actually a
constructor that takes 16 bytes?
All the examples construct arrays and spans, etc from { a, b, c, ... } but
you can't create a uuid directly from { a, b, c ... } ?
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbits_Afe5ONhBYRi2Nd0uhzyYp4rrDXPskn4VuwN4Rfw8g%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbits_Afe5ONhBYRi2Nd0uhzyYp4rrDXPskn4VuwN4Rfw8g%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

[Andrey Semashev]

Post by Corentin
We can discuss more next week about this, but, having used both
boost::uuid and QUuid
recently, a few remarks
* There is a high enough chance that a string you get from some input
not in your control will have braces. Lots of people adopted the
Microsoft notation for some reason, and if std::uuid doesn't prepare for
it, I suspect people will have to check for braces virtually everywhere.
So thumbs up for handling that

I would rather everyone just drop the curly braces than introduce
ambiguity in parsing.

Post by Corentin
* The span constructor is very useful if and only if the order is
determined (notably think deserialization from a binary stream of some
kind).

Constructor is ok, the problem is with the as_bytes() accessor, which
supposedly returns internal representation.

[Marius Bancila]

Ah, I nearly missed this discussion but found it as I was preparing the
slides now required for LEWGI.

So here are the answer to the questions:

0. I will not be able to participate in the meeting. If you can present the
paper again that would be fantastic. In this case, I will send you later
the slides.

1. Looking through the paper again I realized there are actually two
conflicting accounts:

- One that says the byte order is implementation-defined "*Because the
internal representation may not be a straightforward array of bytes and may
have arbitrary endianness iterators are not defined as pointers.*"
- One that says the byte order is fixed: "*The order of the bytes in the
input string reflects directly into the internal representation of the
UUID. That is, for an input string in the
form "aabbccdd-eeff-gghh-iijj-kkllmmnnoopp" or
"{aabbccdd-eeff-gghh-iijj-kkllmmnnoopp}" the
internal byte order of the resulted UUID
is aa,bb,cc,dd,ee,ff,gg,hh,ii,jj,kk,ll,mm,nn,oo,pp.*"

It's a bit late to fix it in this revision and I think it ended up like
this because I tried to incorporate into the paper as much as the feedback
received without realizing it was inconsistent. At a first thought, I would
probably choose the fixed order because it ensures consistency between
implementations.

2. parsing both "xxx..." and "{xxx...}" has been added because it was a hot
feedback topic. I heard that from many people that they would like to have
the bracket version supported.

3. I suppose you would want the initializer_list constructor in addition to
what already exists, right? I don't remember anybody asking for that in the
discussions we had about it. But yes, I think we can add it.

@Bryce, apologizes for the missing email. It was there in the first version
of the paper, but somehow it was removed when I wrote the first revision. I
will make sure that future revisions will have it.

Post by Tony V E
I see the uuid proposal (wg21.link/p0959) is back, and might get looked at
next week in San Diego.
0. will the author be present? (If not, would they like me to present it?)
1. The main question I still have is this idea of whether the internal
byte order is fixed, or implementation defined.
There are begin/end iterators, and they mention impl defined order, but
then there is also as_bytes, returning a span...
But that span is almost useless if the byte order is impl-defined, so I'm
confused.
The difference between fixed order and impl defined order comes down to, I
think, being able to use int compares (or even a 128bit int compare) vs
memcmp() when doing comparisons (for ordering at least - you could do
128bit == regardless of byte order). Is that the main difference?
(And faster compare comes at the cost of more expensive iteration, I think.)
2. why parse both "xxx...." and "{ xxx..... }" (and are spaces allowed
around the brackets?) - how about just specifying "xxx..." only?
3. what about an initializer_list constructor (can you check the length of
an initializer_list at compile time? probably not?) or actually a
constructor that takes 16 bytes?
All the examples construct arrays and spans, etc from { a, b, c, ... } but
you can't create a uuid directly from { a, b, c ... } ?
--
Be seeing you,
Tony

[o***@gmail.com]

Post by Marius Bancila
2. parsing both "xxx..." and "{xxx...}" has been added because it was a
hot feedback topic. I heard that from many people that they would like to
have the bracket version supported.

IMO it should be possible to only accept the format without braces and
spaces, so that part should be optional.

Post by Marius Bancila
A standard uuid library would benefit developers that currently have to

either use operating system specific APIs for creating new uuids or resort
to 3rd party libraries, such as *boost::uuid*

Why isn't a non-standard library good enough for this functionality?

[Marius Bancila]

Post by o***@gmail.com
Why isn't a non-standard library good enough for this functionality?

uuids are widely used as identifiers for various things in many
applications. Having something out of the box should be beneficial for many
developers. The argument that if something is available in a 3rd party
library it shouldn't be standardized would leave out lots of things. Why a
non-standard library is not good enough for file system, calendars, special
math functions, networking, graphics, and many others that I could
enumerate?

Post by o***@gmail.com

Post by Marius Bancila
2. parsing both "xxx..." and "{xxx...}" has been added because it was a
hot feedback topic. I heard that from many people that they would like to
have the bracket version supported.

IMO it should be possible to only accept the format without braces and
spaces, so that part should be optional.

Post by Marius Bancila
A standard uuid library would benefit developers that currently have to

either use operating system specific APIs for creating new uuids or resort
to 3rd party libraries, such as *boost::uuid*
Why isn't a non-standard library good enough for this functionality?
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06d50bb0-2910-43ff-9a05-403724fd7668%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06d50bb0-2910-43ff-9a05-403724fd7668%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Hyman Rosen]

Why a non-standard library is not good enough for file system, calendars,
special math functions, networking, graphics, and many others that I could
enumerate?

Yes, indeed! At the very least, if we must have standardized libraries,
the C++ Standard should be split into a core language standard and a suite
of independent library standards. The only libraries that belong in the
core language standard are those that are needed to implement language
features.

[Olaf van der Spek]

Post by o***@gmail.com
Why isn't a non-standard library good enough for this functionality?

uuids are widely used as identifiers for various things in many applications. Having something out of the box should be beneficial for many developers.

What'd be the benefits over for example boost::uuid?

The argument that if something is available in a 3rd party library it shouldn't be standardized would leave out lots of things. Why a non-standard library is not good enough for file system, calendars, special math functions, networking, graphics, and many others that I could enumerate?

I'm asking you. ;)
AFAIK 2D graphics standardization was halted..
I'm not sure file system should've been standardized..
Networking and especially async operations are more fundamental, but
there too the question should be answered.

IMO it's a question that should be answered for every library proposal.

[Joel FALCOU]

If boost::uuid is enough and has a compelling argument, then maybe
that's what need to be standardized.
Boost provided maybe 80% of the new C++11 library, I can't see why we
can't continue pulling interesting piece of boost that
shown efficiency and proper interface to solve a problem instead of
consuming more man-time.

Post by Olaf van der Spek

Post by o***@gmail.com
Why isn't a non-standard library good enough for this functionality?

uuids are widely used as identifiers for various things in many applications. Having something out of the box should be beneficial for many developers.

What'd be the benefits over for example boost::uuid?

The argument that if something is available in a 3rd party library it shouldn't be standardized would leave out lots of things. Why a non-standard library is not good enough for file system, calendars, special math functions, networking, graphics, and many others that I could enumerate?

I'm asking you. ;)
AFAIK 2D graphics standardization was halted..
I'm not sure file system should've been standardized..
Networking and especially async operations are more fundamental, but
there too the question should be answered.
IMO it's a question that should be answered for every library proposal.

[Andrey Semashev]

Post by Joel FALCOU
If boost::uuid is enough and has a compelling argument, then maybe
that's what need to be standardized.
Boost provided maybe 80% of the new C++11 library, I can't see why we
can't continue pulling interesting piece of boost that
shown efficiency and proper interface to solve a problem instead of
consuming more man-time.

There are some downsides of Boost.UUID that I'm not happy with and that
this proposal may fix. In particular, Boost.UUID mandates uuid internal
implementation as an array of bytes, which prevents some optimizations.
boost::uuid is also uninitalized by default, you have to use
nil_generator to have a nil UUID, which is not an intuitive interface
for that functionality. And string_generator does accept a multitude of
string formats, including braces, which I think is a mistake.

But ultimately, this proposal is quite close to Boost.UUID.

Post by Joel FALCOU

Op ma 5 nov. 2018 om 22:51 schreef Marius Bancila

Post by Marius Bancila

Post by o***@gmail.com
Why isn't a non-standard library good enough for this functionality?

uuids are widely used as identifiers for various things in many
applications. Having something out of the box should be beneficial
for many developers.

What'd be the benefits over for example boost::uuid?

Post by Marius Bancila
The argument that if something is available in a 3rd party library it
shouldn't be standardized would leave out lots of things. Why a
non-standard library is not good enough for file system, calendars,
special math functions, networking, graphics, and many others that I
could enumerate?

I'm asking you. ;)
AFAIK 2D graphics standardization was halted..
I'm not sure file system should've been standardized..
Networking and especially async operations are more fundamental, but
there too the question should be answered.
IMO it's a question that should be answered for every library proposal.

[Tony V E]

Post by Andrey Semashev

Post by Joel FALCOU
If boost::uuid is enough and has a compelling argument, then maybe
that's what need to be standardized.
Boost provided maybe 80% of the new C++11 library, I can't see why we
can't continue pulling interesting piece of boost that
shown efficiency and proper interface to solve a problem instead of
consuming more man-time.

There are some downsides of Boost.UUID that I'm not happy with and that
this proposal may fix. In particular, Boost.UUID mandates uuid internal
implementation as an array of bytes, which prevents some optimizations.

Sorry to ask you to repeat things that we've mentioned before, but where do
these optimizations happen?
IIUC:

- == and != can be same speed regardless of order ? (ie you could compare
it as int128 or whatever)
- < can't be fast if we use the ordering defined in the spec, but could be
if it was just "some order" (ie again, read the bytes as an in128, ignoring
byte order differences)
- we could have < be slow, but offer a fast_uuid_order for use in maps?

Do I understand correctly?

[Gašper Ažman]

As for fast order: p0891r1 proposes std::default_order as a customization
point for a total strong not-necessarily-semantic ordering on *your* type.

So you can have a semantic strong order on < and <=> and a fast order as
default_order.

Also, this is a shameless plug. It's about to be discussed and hopefully
waved through to LWG.

Post by Tony V E

Post by Andrey Semashev

Post by Joel FALCOU
If boost::uuid is enough and has a compelling argument, then maybe
that's what need to be standardized.
Boost provided maybe 80% of the new C++11 library, I can't see why we
can't continue pulling interesting piece of boost that
shown efficiency and proper interface to solve a problem instead of
consuming more man-time.

There are some downsides of Boost.UUID that I'm not happy with and that
this proposal may fix. In particular, Boost.UUID mandates uuid internal
implementation as an array of bytes, which prevents some optimizations.

Sorry to ask you to repeat things that we've mentioned before, but where
do these optimizations happen?
- == and != can be same speed regardless of order ? (ie you could compare
it as int128 or whatever)
- < can't be fast if we use the ordering defined in the spec, but could be
if it was just "some order" (ie again, read the bytes as an in128, ignoring
byte order differences)
- we could have < be slow, but offer a fast_uuid_order for use in maps?
Do I understand correctly?
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu3zk6taGjbuB7bCumwU1RSOByij6mNkgSMi256QWgXcw%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu3zk6taGjbuB7bCumwU1RSOByij6mNkgSMi256QWgXcw%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

[Andrey Semashev]

Post by Andrey Semashev

Post by Joel FALCOU
If boost::uuid is enough and has a compelling argument, then maybe
that's what need to be standardized.
Boost provided maybe 80% of the new C++11 library, I can't see why we
can't continue pulling interesting piece of boost that
shown efficiency and proper interface to solve a problem instead of
consuming more man-time.

There are some downsides of Boost.UUID that I'm not happy with and that
this proposal may fix. In particular, Boost.UUID mandates uuid internal
implementation as an array of bytes, which prevents some optimizations.

Sorry to ask you to repeat things that we've mentioned before, but where do these optimizations happen?
- == and != can be same speed regardless of order ? (ie you could compare it as int128 or whatever)

Yes.

- < can't be fast if we use the ordering defined in the spec, but could be if it was just "some order" (ie again, read the bytes as an in128, ignoring byte order differences)

Yes, ordering (i.e. operator<) is the main concern. I think, the
ordering behavior (i.e., that the operator< implements lexicographical
or other defined ordering) could be useful for interoperation between
implementations. For example, if you serialize an ordered sequence of
UUIDs in one program, you can be sure that it is ordered the same way
in any other program, built with another implementation. I'm not sure
how useful that would be, but it's worth considering, IMHO.

- we could have < be slow, but offer a fast_uuid_order for use in maps?

I really don't like the idea of having special ordering predicates
because it will just be too complicated and obscure to use and
ultimately noone will care to use them. If you have the fast one, why
is it not the default? Besides, function objects are not always
convenient to use, e.g. when you have to write a composite predicate
or otherwise have to spell the comparison in a function body. No, just
allow for the most optimal implementation of operator< and let the
other machinery, like std::default_order, do its regular job.

Besides ordering, string operations could be optimized with SIMD as
well, and having a mandatory internal representation could penalize
that.

[Andrey Semashev]

On Wed, Nov 7, 2018 at 2:41 AM Andrey Semashev

Post by Andrey Semashev

Post by Andrey Semashev

Post by Joel FALCOU
If boost::uuid is enough and has a compelling argument, then maybe
that's what need to be standardized.
Boost provided maybe 80% of the new C++11 library, I can't see why we
can't continue pulling interesting piece of boost that
shown efficiency and proper interface to solve a problem instead of
consuming more man-time.

There are some downsides of Boost.UUID that I'm not happy with and that
this proposal may fix. In particular, Boost.UUID mandates uuid internal
implementation as an array of bytes, which prevents some optimizations.

Sorry to ask you to repeat things that we've mentioned before, but where do these optimizations happen?
- == and != can be same speed regardless of order ? (ie you could compare it as int128 or whatever)

Yes.

- < can't be fast if we use the ordering defined in the spec, but could be if it was just "some order" (ie again, read the bytes as an in128, ignoring byte order differences)

Yes, ordering (i.e. operator<) is the main concern. I think, the
ordering behavior (i.e., that the operator< implements lexicographical
or other defined ordering) could be useful for interoperation between
implementations. For example, if you serialize an ordered sequence of
UUIDs in one program, you can be sure that it is ordered the same way
in any other program, built with another implementation. I'm not sure
how useful that would be, but it's worth considering, IMHO.

- we could have < be slow, but offer a fast_uuid_order for use in maps?

I really don't like the idea of having special ordering predicates
because it will just be too complicated and obscure to use and
ultimately noone will care to use them. If you have the fast one, why
is it not the default? Besides, function objects are not always
convenient to use, e.g. when you have to write a composite predicate
or otherwise have to spell the comparison in a function body. No, just
allow for the most optimal implementation of operator< and let the
other machinery, like std::default_order, do its regular job.
Besides ordering, string operations could be optimized with SIMD as
well, and having a mandatory internal representation could penalize
that.

To be clear, by "string operations" I mean to/from string conversions.
By the way, the additional flexibility with string formats makes this
kind of optimization more difficult.

[Balog Pal]

2018. november 6., kedd 8:51:52 UTC+1 időpontban Olaf van der Spek a

Post by Olaf van der Spek
AFAIK 2D graphics standardization was halted..

It was, but not because lack of desire for the feature. It was halted
because the result this far is, while not even covering a lot of needed
things, is huge in text and complexity.

There was an estimation that review of the material would have consumed the
full capacity of the groups for the next 3 meetings (IIRC), so effectively
preventing progress on everything else on the table.

OTOH in recent news we heard that enough people are still interested so the
related study group is getting revived.