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 ... } ?

--

Be seeing you,

Tony

[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.

> --
> 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 email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> 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

--

[Andrey Semashev]

On 11/1/18 5:35 PM, Corentin wrote:
> 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.

> * 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.

[olafv...@gmail.com]

Op donderdag 1 november 2018 23:20:03 UTC+1 schreef 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.

> 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]

> 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?

--

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 email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

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.

[Hyman Rosen]

On Mon, Nov 5, 2018 at 4:51 PM Marius Bancila <marius....@gmail.com> wrote:

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]

Op ma 5 nov. 2018 om 22:51 schreef Marius Bancila <marius....@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.




--
Olaf

[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.

[Andrey Semashev]

On 11/6/18 11:23 AM, Joel FALCOU wrote:
> 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.

[Balog Pal]

2018. november 6., kedd 8:51:52 UTC+1 időpontban Olaf van der Spek a következőt írta:

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.

[Tony V E]

On Tue, Nov 6, 2018 at 5:23 AM Andrey Semashev <andrey....@gmail.com> wrote:

On 11/6/18 11:23 AM, Joel FALCOU wrote:
> 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.

--

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 email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu3zk6taGjbuB7bCumwU1RSOByij6mNkgSMi256QWgXcw%40mail.gmail.com.

[Andrey Semashev]

On Wed, Nov 7, 2018 at 12:59 AM Tony V E <tvan...@gmail.com> wrote:
> On Tue, Nov 6, 2018 at 5:23 AM Andrey Semashev <andrey....@gmail.com> wrote:
>>
>> On 11/6/18 11:23 AM, Joel FALCOU wrote:
>> > 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)

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

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.