--00000000000037caa1057993c2eb
Content-Type: text/plain; charset="UTF-8"

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

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

--00000000000037caa1057993c2eb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I see the uuid proposal (wg21.link/p0959) is back, an=
d might get looked at next week in San Diego.</div><div><br></div><div>Ques=
tions:</div><div><br></div><div>0. will the author be present?=C2=A0 (If no=
t, would they like me to present it?)<br></div><div><br></div><div>1. The m=
ain question I still have is this idea of whether the internal byte order i=
s fixed, or implementation defined.<div class=3D"gmail-messageCozy-2JPAPA g=
mail-message-1PNnaP"><div class=3D"gmail-contentCozy-3XX413 gmail-content-3=
dzVd8"><div class=3D"gmail-containerCozy-336-Cz gmail-container-206Blv"><di=
v class=3D"gmail-markup-2BOw-j">There are begin/end iterators, and they men=
tion impl defined order, but then there is also as_bytes, returning a span.=
...</div></div></div></div><div class=3D"gmail-messageCozy-2JPAPA gmail-mess=
age-1PNnaP"><div class=3D"gmail-contentCozy-3XX413 gmail-content-3dzVd8"><d=
iv class=3D"gmail-containerCozy-336-Cz gmail-container-206Blv"><div class=
=3D"gmail-markup-2BOw-j">But that span is almost useless if the byte order =
is impl-defined, so I&#39;m confused.<br></div></div></div></div><div class=
=3D"gmail-messageCozy-2JPAPA gmail-message-1PNnaP"><div class=3D"gmail-cont=
entCozy-3XX413 gmail-content-3dzVd8"><div class=3D"gmail-containerCozy-336-=
Cz gmail-container-206Blv"><div class=3D"gmail-markup-2BOw-j"><br></div><di=
v class=3D"gmail-markup-2BOw-j">
<div class=3D"gmail-messageCozy-2JPAPA gmail-message-1PNnaP"><div class=3D"=
gmail-contentCozy-3XX413 gmail-content-3dzVd8"><div class=3D"gmail-containe=
rCozy-336-Cz gmail-container-206Blv"><div class=3D"gmail-markup-2BOw-j">The=
 difference between fixed order and impl defined order comes down to, I thi=
nk, 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 =3D=
=3D regardless of byte order).=C2=A0 Is that the main difference?<br></div>=
</div></div></div>

</div><div class=3D"gmail-markup-2BOw-j">(And faster compare comes at the c=
ost of more expensive iteration, I think.)<br></div></div><div class=3D"gma=
il-containerCozy-336-Cz gmail-container-206Blv"><br></div><div class=3D"gma=
il-containerCozy-336-Cz gmail-container-206Blv"><br></div><div class=3D"gma=
il-containerCozy-336-Cz gmail-container-206Blv">2. why parse both &quot;xxx=
.....&quot; and &quot;{ xxx..... }&quot; (and are spaces allowed around the =
brackets?) - how about just specifying &quot;xxx...&quot; only?</div><div c=
lass=3D"gmail-containerCozy-336-Cz gmail-container-206Blv"><br></div><div c=
lass=3D"gmail-containerCozy-336-Cz gmail-container-206Blv"><br></div><div c=
lass=3D"gmail-containerCozy-336-Cz gmail-container-206Blv">3. what about an=
 initializer_list constructor (can you check the length of an initializer_l=
ist at compile time? probably not?)=C2=A0 or actually a constructor that ta=
kes 16 bytes?</div><div class=3D"gmail-containerCozy-336-Cz gmail-container=
-206Blv">All the examples construct arrays and spans, etc from { a, b, c, .=
... } but you can&#39;t create a uuid directly from { a, b, c ... } ?</div><=
div class=3D"gmail-containerCozy-336-Cz gmail-container-206Blv"><br></div><=
div class=3D"gmail-containerCozy-336-Cz gmail-container-206Blv"><br></div><=
div class=3D"gmail-containerCozy-336-Cz gmail-container-206Blv"><div class=
=3D"gmail-markup-2BOw-j"><br></div><br></div></div></div></div><div><br></d=
iv><br>-- <br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></di=
v></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbits_Afe5ONhBYRi2Nd0uhzyYp4rrDXP=
skn4VuwN4Rfw8g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbits_Afe5ONh=
BYRi2Nd0uhzyYp4rrDXPskn4VuwN4Rfw8g%40mail.gmail.com</a>.<br />

--00000000000037caa1057993c2eb--

.

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.
On Wed, Oct 31, 2018 at 10:33 PM Tony V E <tvaneerd@gmail.com> wrote:
>
> I see the uuid proposal (wg21.link/p0959) is back, and might get looked a=
t 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 by=
te order is fixed, or implementation defined.
> There are begin/end iterators, and they mention impl defined order, but t=
hen 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 m=
emcmp() when doing comparisons (for ordering at least - you could do 128bit=
 =3D=3D regardless of byte order).  Is that the main difference?
> (And faster compare comes at the cost of more expensive iteration, I thin=
k.)
>
>
> 2. why parse both "xxx...." and "{ xxx..... }" (and are spaces allowed ar=
ound the brackets?) - how about just specifying "xxx..." only?
>
>
> 3. what about an initializer_list constructor (can you check the length o=
f an initializer_list at compile time? probably not?)  or actually a constr=
uctor that takes 16 bytes?
> All the examples construct arrays and spans, etc from { a, b, c, ... } bu=
t 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=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CAOHCbits_Afe5ONhBYRi2Nd0uhzyYp4rrDXPskn4VuwN4=
Rfw8g%40mail.gmail.com.



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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAP3wax9KsbNXCKJZkt2eG2GyFUnuc5jykK%2BBSDvGQTj1D=
%2BYLcw%40mail.gmail.com.

.

--0000000000005ef01e05799b54af
Content-Type: text/plain; charset="UTF-8"

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


On Thu, 1 Nov 2018 at 06:33 Tony V E <tvaneerd@gmail.com> wrote:

> 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
>
> --
> 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-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbits_Afe5ONhBYRi2Nd0uhzyYp4rrDXPskn4VuwN4Rfw8g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSj8DdzDi_Hr6V%2BFDRtFos_JpeHFbd22_-oDoSEGti0vXA%40mail.gmail.com.

--0000000000005ef01e05799b54af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We can discuss more next week about this, but, having used=
 both boost::uuid=C2=A0and QUuid<div>recently, a few remarks</div><div>=C2=
=A0</div><div>* There is a high enough chance that a string you get from so=
me input not in your control will have braces. Lots of people adopted the M=
icrosoft notation for some reason, and if std::uuid=C2=A0doesn&#39;t prepar=
e for it, I suspect people will have to check for braces virtually everywhe=
re. So thumbs up for handling that</div><div><br></div><div>* The span cons=
tructor is very useful if and only if the order is determined (notably thin=
k deserialization from a binary stream of some kind).</div><div><br></div><=
div><br></div><div>Corentin</div><div><br></div><div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr">On Thu, 1 Nov 2018 at 06:33 Tony V E &lt;<a href=
=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I see the uuid proposal=
 (wg21.link/p0959) is back, and might get looked at next week in San Diego.=
</div><div><br></div><div>Questions:</div><div><br></div><div>0. will the a=
uthor be present?=C2=A0 (If not, would they like me to present it?)<br></di=
v><div><br></div><div>1. The main question I still have is this idea of whe=
ther the internal byte order is fixed, or implementation defined.<div class=
=3D"m_3809770517794674155gmail-messageCozy-2JPAPA m_3809770517794674155gmai=
l-message-1PNnaP"><div class=3D"m_3809770517794674155gmail-contentCozy-3XX4=
13 m_3809770517794674155gmail-content-3dzVd8"><div class=3D"m_3809770517794=
674155gmail-containerCozy-336-Cz m_3809770517794674155gmail-container-206Bl=
v"><div class=3D"m_3809770517794674155gmail-markup-2BOw-j">There are begin/=
end iterators, and they mention impl defined order, but then there is also =
as_bytes, returning a span...</div></div></div></div><div class=3D"m_380977=
0517794674155gmail-messageCozy-2JPAPA m_3809770517794674155gmail-message-1P=
NnaP"><div class=3D"m_3809770517794674155gmail-contentCozy-3XX413 m_3809770=
517794674155gmail-content-3dzVd8"><div class=3D"m_3809770517794674155gmail-=
containerCozy-336-Cz m_3809770517794674155gmail-container-206Blv"><div clas=
s=3D"m_3809770517794674155gmail-markup-2BOw-j">But that span is almost usel=
ess if the byte order is impl-defined, so I&#39;m confused.<br></div></div>=
</div></div><div class=3D"m_3809770517794674155gmail-messageCozy-2JPAPA m_3=
809770517794674155gmail-message-1PNnaP"><div class=3D"m_3809770517794674155=
gmail-contentCozy-3XX413 m_3809770517794674155gmail-content-3dzVd8"><div cl=
ass=3D"m_3809770517794674155gmail-containerCozy-336-Cz m_380977051779467415=
5gmail-container-206Blv"><div class=3D"m_3809770517794674155gmail-markup-2B=
Ow-j"><br></div><div class=3D"m_3809770517794674155gmail-markup-2BOw-j">
<div class=3D"m_3809770517794674155gmail-messageCozy-2JPAPA m_3809770517794=
674155gmail-message-1PNnaP"><div class=3D"m_3809770517794674155gmail-conten=
tCozy-3XX413 m_3809770517794674155gmail-content-3dzVd8"><div class=3D"m_380=
9770517794674155gmail-containerCozy-336-Cz m_3809770517794674155gmail-conta=
iner-206Blv"><div class=3D"m_3809770517794674155gmail-markup-2BOw-j">The di=
fference 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 =3D=3D =
regardless of byte order).=C2=A0 Is that the main difference?<br></div></di=
v></div></div>

</div><div class=3D"m_3809770517794674155gmail-markup-2BOw-j">(And faster c=
ompare comes at the cost of more expensive iteration, I think.)<br></div></=
div><div class=3D"m_3809770517794674155gmail-containerCozy-336-Cz m_3809770=
517794674155gmail-container-206Blv"><br></div><div class=3D"m_3809770517794=
674155gmail-containerCozy-336-Cz m_3809770517794674155gmail-container-206Bl=
v"><br></div><div class=3D"m_3809770517794674155gmail-containerCozy-336-Cz =
m_3809770517794674155gmail-container-206Blv">2. why parse both &quot;xxx...=
..&quot; and &quot;{ xxx..... }&quot; (and are spaces allowed around the bra=
ckets?) - how about just specifying &quot;xxx...&quot; only?</div><div clas=
s=3D"m_3809770517794674155gmail-containerCozy-336-Cz m_3809770517794674155g=
mail-container-206Blv"><br></div><div class=3D"m_3809770517794674155gmail-c=
ontainerCozy-336-Cz m_3809770517794674155gmail-container-206Blv"><br></div>=
<div class=3D"m_3809770517794674155gmail-containerCozy-336-Cz m_38097705177=
94674155gmail-container-206Blv">3. what about an initializer_list construct=
or (can you check the length of an initializer_list at compile time? probab=
ly not?)=C2=A0 or actually a constructor that takes 16 bytes?</div><div cla=
ss=3D"m_3809770517794674155gmail-containerCozy-336-Cz m_3809770517794674155=
gmail-container-206Blv">All the examples construct arrays and spans, etc fr=
om { a, b, c, ... } but you can&#39;t create a uuid directly from { a, b, c=
 ... } ?</div><div class=3D"m_3809770517794674155gmail-containerCozy-336-Cz=
 m_3809770517794674155gmail-container-206Blv"><br></div><div class=3D"m_380=
9770517794674155gmail-containerCozy-336-Cz m_3809770517794674155gmail-conta=
iner-206Blv"><br></div><div class=3D"m_3809770517794674155gmail-containerCo=
zy-336-Cz m_3809770517794674155gmail-container-206Blv"><div class=3D"m_3809=
770517794674155gmail-markup-2BOw-j"><br></div><br></div></div></div></div><=
div><br></div><br>-- <br><div dir=3D"ltr" class=3D"m_3809770517794674155gma=
il_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be s=
eeing you,<br></div>Tony<br></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbits_Afe5ONhBYRi2Nd0uhzyYp4rrDXP=
skn4VuwN4Rfw8g%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAOHCbits_Afe5ONhBYRi2Nd0uhzyYp4rrDXPskn4VuwN4Rfw8g%40mail.gmail.com</=
a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSj8DdzDi_Hr6V%2BFDRtFos_Jpe=
HFbd22_-oDoSEGti0vXA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BS=
j8DdzDi_Hr6V%2BFDRtFos_JpeHFbd22_-oDoSEGti0vXA%40mail.gmail.com</a>.<br />

--0000000000005ef01e05799b54af--

.

On 11/1/18 5:35 PM, Corentin wrote:
> We can discuss more next week about this, but, having used both=20
> boost::uuid=C2=A0and QUuid
> recently, a few remarks
> * There is a high enough chance that a string you get from some input=20
> not in your control will have braces. Lots of people adopted the=20
> Microsoft notation for some reason, and if std::uuid=C2=A0doesn't prepare=
 for=20
> it, I suspect people will have to check for braces virtually everywhere.=
=20
> So thumbs up for handling that

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

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

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/97d0477e-cba2-90e1-0646-52cf615490a6%40gmail.com=
..

.

--000000000000e71b9c0579a1d16f
Content-Type: text/plain; charset="UTF-8"

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.

On Thu, Nov 1, 2018 at 7:33 AM Tony V E <tvaneerd@gmail.com> wrote:

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

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASx5cWmiDHhbXDGE%3DMH1dapAL%3DOp9C%2BAgTdL8dKP3G08Zg%40mail.gmail.com.

--000000000000e71b9c0579a1d16f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ah, I nearly missed this discussion but found it as I was =
preparing the slides now required for LEWGI.<div><br></div><div>So here are=
 the answer to the questions:</div><div><br></div><div>0. I will not be abl=
e to participate in the meeting. If you can present the paper again that wo=
uld be fantastic. In this case, I will send you later the slides.</div><div=
><br></div><div>1. Looking through the paper again I realized there are act=
ually two conflicting accounts:</div><div><ul><li>One that says the byte or=
der is implementation-defined &quot;<i>Because the internal representation =
may not be a straightforward array of bytes and may have arbitrary endianne=
ss iterators are not defined as pointers.</i>&quot;<br></li><li>One that sa=
ys the byte order is fixed: &quot;<i>The order of the bytes in the input st=
ring reflects directly into the internal representation of the UUID. That i=
s, for an input string in the form=C2=A0<code style=3D"box-sizing:border-bo=
x;font-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,Cou=
rier,monospace;font-size:13.6px;padding:0.2em 0.4em;margin:0px;background-c=
olor:rgba(27,31,35,0.05);border-radius:3px;color:rgb(36,41,46)">&quot;aabbc=
cdd-eeff-gghh-iijj-kkllmmnnoopp&quot;</code><span style=3D"color:rgb(36,41,=
46);font-family:-apple-system,system-ui,&quot;Segoe UI&quot;,Helvetica,Aria=
l,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot=
;Segoe UI Symbol&quot;;font-size:16px">=C2=A0or=C2=A0</span><code style=3D"=
box-sizing:border-box;font-family:SFMono-Regular,Consolas,&quot;Liberation =
Mono&quot;,Menlo,Courier,monospace;font-size:13.6px;padding:0.2em 0.4em;mar=
gin:0px;background-color:rgba(27,31,35,0.05);border-radius:3px;color:rgb(36=
,41,46)">&quot;{aabbccdd-eeff-gghh-iijj-kkllmmnnoopp}&quot;</code><span sty=
le=3D"color:rgb(36,41,46);font-family:-apple-system,system-ui,&quot;Segoe U=
I&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Sego=
e UI Emoji&quot;,&quot;Segoe UI Symbol&quot;;font-size:16px">=C2=A0the inte=
rnal byte order of the resulted UUID is=C2=A0</span><code style=3D"box-sizi=
ng:border-box;font-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quo=
t;,Menlo,Courier,monospace;font-size:13.6px;padding:0.2em 0.4em;margin:0px;=
background-color:rgba(27,31,35,0.05);border-radius:3px;color:rgb(36,41,46)"=
>aa,bb,cc,dd,ee,ff,gg,hh,ii,jj,kk,ll,mm,nn,oo,pp</code><span style=3D"color=
:rgb(36,41,46);font-family:-apple-system,system-ui,&quot;Segoe UI&quot;,Hel=
vetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&=
quot;,&quot;Segoe UI Symbol&quot;;font-size:16px">.</span></i>&quot;</li></=
ul></div><div>It&#39;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 a=
s the feedback received without realizing it was inconsistent. At a first t=
hought, I would probably choose the fixed order because it ensures consiste=
ncy between implementations.</div><div><br></div><div>2. parsing both &quot=
;xxx...&quot; and &quot;{xxx...}&quot; 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.<br></div><div><br></div><div>3. I suppose yo=
u would want the initializer_list constructor in addition to what already e=
xists, right? I don&#39;t remember anybody asking for that in the discussio=
ns we had about it. But yes, I think we can add it.</div><div><br></div><di=
v>@Bryce, apologizes for the missing email. It was there in the first versi=
on of the paper, but somehow it was removed when I wrote the first revision=
.. I will make sure that future revisions will have it.</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Nov 1, 2018 at 7:33 AM Tony =
V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gm=
ail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>I see the uuid proposal (wg21.link/p0959) is back, and might get =
looked at next week in San Diego.</div><div><br></div><div>Questions:</div>=
<div><br></div><div>0. will the author be present?=C2=A0 (If not, would the=
y like me to present it?)<br></div><div><br></div><div>1. The main question=
 I still have is this idea of whether the internal byte order is fixed, or =
implementation defined.<div class=3D"m_8218018241650833050m_361133247026176=
5865gmail-messageCozy-2JPAPA m_8218018241650833050m_3611332470261765865gmai=
l-message-1PNnaP"><div class=3D"m_8218018241650833050m_3611332470261765865g=
mail-contentCozy-3XX413 m_8218018241650833050m_3611332470261765865gmail-con=
tent-3dzVd8"><div class=3D"m_8218018241650833050m_3611332470261765865gmail-=
containerCozy-336-Cz m_8218018241650833050m_3611332470261765865gmail-contai=
ner-206Blv"><div class=3D"m_8218018241650833050m_3611332470261765865gmail-m=
arkup-2BOw-j">There are begin/end iterators, and they mention impl defined =
order, but then there is also as_bytes, returning a span...</div></div></di=
v></div><div class=3D"m_8218018241650833050m_3611332470261765865gmail-messa=
geCozy-2JPAPA m_8218018241650833050m_3611332470261765865gmail-message-1PNna=
P"><div class=3D"m_8218018241650833050m_3611332470261765865gmail-contentCoz=
y-3XX413 m_8218018241650833050m_3611332470261765865gmail-content-3dzVd8"><d=
iv class=3D"m_8218018241650833050m_3611332470261765865gmail-containerCozy-3=
36-Cz m_8218018241650833050m_3611332470261765865gmail-container-206Blv"><di=
v class=3D"m_8218018241650833050m_3611332470261765865gmail-markup-2BOw-j">B=
ut that span is almost useless if the byte order is impl-defined, so I&#39;=
m confused.<br></div></div></div></div><div class=3D"m_8218018241650833050m=
_3611332470261765865gmail-messageCozy-2JPAPA m_8218018241650833050m_3611332=
470261765865gmail-message-1PNnaP"><div class=3D"m_8218018241650833050m_3611=
332470261765865gmail-contentCozy-3XX413 m_8218018241650833050m_361133247026=
1765865gmail-content-3dzVd8"><div class=3D"m_8218018241650833050m_361133247=
0261765865gmail-containerCozy-336-Cz m_8218018241650833050m_361133247026176=
5865gmail-container-206Blv"><div class=3D"m_8218018241650833050m_3611332470=
261765865gmail-markup-2BOw-j"><br></div><div class=3D"m_8218018241650833050=
m_3611332470261765865gmail-markup-2BOw-j">
<div class=3D"m_8218018241650833050m_3611332470261765865gmail-messageCozy-2=
JPAPA m_8218018241650833050m_3611332470261765865gmail-message-1PNnaP"><div =
class=3D"m_8218018241650833050m_3611332470261765865gmail-contentCozy-3XX413=
 m_8218018241650833050m_3611332470261765865gmail-content-3dzVd8"><div class=
=3D"m_8218018241650833050m_3611332470261765865gmail-containerCozy-336-Cz m_=
8218018241650833050m_3611332470261765865gmail-container-206Blv"><div class=
=3D"m_8218018241650833050m_3611332470261765865gmail-markup-2BOw-j">The diff=
erence between fixed order and impl defined order comes down to, I think, b=
eing able to use int compares (or even a 128bit int compare) vs memcmp() wh=
en doing comparisons (for ordering at least - you could do 128bit =3D=3D re=
gardless of byte order).=C2=A0 Is that the main difference?<br></div></div>=
</div></div>

</div><div class=3D"m_8218018241650833050m_3611332470261765865gmail-markup-=
2BOw-j">(And faster compare comes at the cost of more expensive iteration, =
I think.)<br></div></div><div class=3D"m_8218018241650833050m_3611332470261=
765865gmail-containerCozy-336-Cz m_8218018241650833050m_3611332470261765865=
gmail-container-206Blv"><br></div><div class=3D"m_8218018241650833050m_3611=
332470261765865gmail-containerCozy-336-Cz m_8218018241650833050m_3611332470=
261765865gmail-container-206Blv"><br></div><div class=3D"m_8218018241650833=
050m_3611332470261765865gmail-containerCozy-336-Cz m_8218018241650833050m_3=
611332470261765865gmail-container-206Blv">2. why parse both &quot;xxx....&q=
uot; and &quot;{ xxx..... }&quot; (and are spaces allowed around the bracke=
ts?) - how about just specifying &quot;xxx...&quot; only?</div><div class=
=3D"m_8218018241650833050m_3611332470261765865gmail-containerCozy-336-Cz m_=
8218018241650833050m_3611332470261765865gmail-container-206Blv"><br></div><=
div class=3D"m_8218018241650833050m_3611332470261765865gmail-containerCozy-=
336-Cz m_8218018241650833050m_3611332470261765865gmail-container-206Blv"><b=
r></div><div class=3D"m_8218018241650833050m_3611332470261765865gmail-conta=
inerCozy-336-Cz m_8218018241650833050m_3611332470261765865gmail-container-2=
06Blv">3. what about an initializer_list constructor (can you check the len=
gth of an initializer_list at compile time? probably not?)=C2=A0 or actuall=
y a constructor that takes 16 bytes?</div><div class=3D"m_82180182416508330=
50m_3611332470261765865gmail-containerCozy-336-Cz m_8218018241650833050m_36=
11332470261765865gmail-container-206Blv">All the examples construct arrays =
and spans, etc from { a, b, c, ... } but you can&#39;t create a uuid direct=
ly from { a, b, c ... } ?</div><div class=3D"m_8218018241650833050m_3611332=
470261765865gmail-containerCozy-336-Cz m_8218018241650833050m_3611332470261=
765865gmail-container-206Blv"><br></div><div class=3D"m_8218018241650833050=
m_3611332470261765865gmail-containerCozy-336-Cz m_8218018241650833050m_3611=
332470261765865gmail-container-206Blv"><br></div><div class=3D"m_8218018241=
650833050m_3611332470261765865gmail-containerCozy-336-Cz m_8218018241650833=
050m_3611332470261765865gmail-container-206Blv"><div class=3D"m_82180182416=
50833050m_3611332470261765865gmail-markup-2BOw-j"><br></div><br></div></div=
></div></div><div><br></div><br>-- <br><div dir=3D"ltr" class=3D"m_82180182=
41650833050m_3611332470261765865gmail_signature" data-smartmail=3D"gmail_si=
gnature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>=
</div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASx5cWmiDHhbXDGE%3DMH1dapAL%3D=
Op9C%2BAgTdL8dKP3G08Zg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtAS=
x5cWmiDHhbXDGE%3DMH1dapAL%3DOp9C%2BAgTdL8dKP3G08Zg%40mail.gmail.com</a>.<br=
 />

--000000000000e71b9c0579a1d16f--

.

------=_Part_304_532505696.1541405969926
Content-Type: multipart/alternative;
 boundary="----=_Part_305_913773984.1541405969926"

------=_Part_305_913773984.1541405969926
Content-Type: text/plain; charset="UTF-8"

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?

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

------=_Part_305_913773984.1541405969926
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op donderdag 1 november 2018 23:20:03 UTC+1 schreef Marius=
 Bancila:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>2. parsing both &quot;xxx...&quot; and &quot;{xxx...}&quot; has been added=
 because it was a hot feedback topic. I heard that from many people that th=
ey would like to have the bracket version supported.</div></div></blockquot=
e><div><br></div><div>IMO it should be possible to only accept the format w=
ithout braces and spaces, so that part should be optional.</div><div><br></=
div><div>&gt;=C2=A0<span style=3D"color: rgb(0, 0, 0); white-space: pre-wra=
p;">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*</span></div><div><span style=
=3D"color: rgb(0, 0, 0); white-space: pre-wrap;"><br></span></div><div><spa=
n style=3D"color: rgb(0, 0, 0); white-space: pre-wrap;">Why isn&#39;t a non=
-standard library good enough for this functionality?</span></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/06d50bb0-2910-43ff-9a05-403724fd7668%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06d50bb0-2910-43ff-9a05-403724fd7668=
%40isocpp.org</a>.<br />

------=_Part_305_913773984.1541405969926--

------=_Part_304_532505696.1541405969926--

.

--0000000000002fe31c0579f1e2a2
Content-Type: text/plain; charset="UTF-8"

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


On Mon, Nov 5, 2018 at 10:19 AM <olafvdspek@gmail.com> wrote:

> 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?
>
> --
> 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-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06d50bb0-2910-43ff-9a05-403724fd7668%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASy5baaeZvGzcPDGVk5dJ4C7TwQtbYcG%2BU3f1b-LBaibuA%40mail.gmail.com.

--0000000000002fe31c0579f1e2a2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><span style=3D"color:rgb(0,0,0);white-space:pre-wrap"=
>&gt; Why isn&#39;t a non-standard library good enough for this functionali=
ty?</span><br></div><div><span style=3D"color:rgb(0,0,0);white-space:pre-wr=
ap"><br></span></div><div><span style=3D"color:rgb(0,0,0);white-space:pre-w=
rap">uuids are widely used as identifiers for various things in many applic=
ations. Having something out of the box should be beneficial for many devel=
opers. The argument that if something is available in a 3rd party library i=
t shouldn&#39;t be standardized would leave out lots of things. Why a non-s=
tandard library is not good enough for file system, calendars, special math=
 functions, networking, graphics, and many others that I could enumerate?</=
span></div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Nov =
5, 2018 at 10:19 AM &lt;<a href=3D"mailto:olafvdspek@gmail.com">olafvdspek@=
gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">Op donderdag 1 november 2018 23:20:03 UTC+1 schreef Marius Bancila=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>2. parsing b=
oth &quot;xxx...&quot; and &quot;{xxx...}&quot; has been added because it w=
as a hot feedback topic. I heard that from many people that they would like=
 to have the bracket version supported.</div></div></blockquote><div><br></=
div><div>IMO it should be possible to only accept the format without braces=
 and spaces, so that part should be optional.</div><div><br></div><div>&gt;=
=C2=A0<span style=3D"color:rgb(0,0,0);white-space:pre-wrap">A standard uuid=
 library would benefit developers that currently have to either use operati=
ng system specific APIs for creating new uuids or resort to 3rd party libra=
ries, such as *boost::uuid*</span></div><div><span style=3D"color:rgb(0,0,0=
);white-space:pre-wrap"><br></span></div><div><span style=3D"color:rgb(0,0,=
0);white-space:pre-wrap">Why isn&#39;t a non-standard library good enough f=
or this functionality?</span></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/06d50bb0-2910-43ff-9a05-403724fd7668%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06d50bb0-2910-=
43ff-9a05-403724fd7668%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASy5baaeZvGzcPDGVk5dJ4C7TwQtbY=
cG%2BU3f1b-LBaibuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASy5ba=
aeZvGzcPDGVk5dJ4C7TwQtbYcG%2BU3f1b-LBaibuA%40mail.gmail.com</a>.<br />

--0000000000002fe31c0579f1e2a2--

.

--00000000000001ddf10579f25328
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 5, 2018 at 4:51 PM Marius Bancila <marius.bancila@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.

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbZaNaZ_ihBNExUa9myBishoH6VRXweVmnR2VaLqBVt5A%40mail.gmail.com.

--00000000000001ddf10579f25328
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Nov 5,=
 2018 at 4:51 PM Marius Bancila &lt;<a href=3D"mailto:marius.bancila@gmail.=
com">marius.bancila@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><span style=3D"color:rgb(0,0,0);white-space=
:pre-wrap">Why a non-standard library is not good enough for file system, c=
alendars, special math functions, networking, graphics, and many others tha=
t I could enumerate?</span></div></div></blockquote><div><br>Yes, indeed!=
=C2=A0 At the very least, if we must have standardized libraries, the C++ S=
tandard should be split into a core language standard and a suite of indepe=
ndent library standards.=C2=A0 The only libraries that belong in the core l=
anguage standard are those that are needed to implement language features.<=
/div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbZaNaZ_ihBNExUa9myBishoH6VRXwe=
VmnR2VaLqBVt5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbZaNaZ_ihB=
NExUa9myBishoH6VRXweVmnR2VaLqBVt5A%40mail.gmail.com</a>.<br />

--00000000000001ddf10579f25328--

.

Op ma 5 nov. 2018 om 22:51 schreef Marius Bancila <marius.bancila@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 applicati=
ons. Having something out of the box should be beneficial for many develope=
rs.

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

> The argument that if something is available in a 3rd party library it sho=
uldn't be standardized would leave out lots of things. Why a non-standard l=
ibrary is not good enough for file system, calendars, special math function=
s, 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.




--=20
Olaf

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7U3HNiC-QW8-iGJUhc1TWVaFNwpdKwDLFEvbigOy6XhDm=
nLg%40mail.gmail.com.

.

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


On 06/11/2018 08:51, Olaf van der Spek wrote:
> Op ma 5 nov. 2018 om 22:51 schreef Marius Bancila <marius.bancila@gmail.c=
om>:
>>> Why isn't a non-standard library good enough for this functionality?
>> uuids are widely used as identifiers for various things in many applicat=
ions. Having something out of the box should be beneficial for many develop=
ers.
> What'd be the benefits over for example boost::uuid?
>
>> The argument that if something is available in a 3rd party library it sh=
ouldn't be standardized would leave out lots of things. Why a non-standard =
library is not good enough for file system, calendars, special math functio=
ns, 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.
>
>
>
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/25b7bb72-c2a0-284a-6795-6a82687bcef4%40gmail.com=
..

.

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.

> On 06/11/2018 08:51, Olaf van der Spek wrote:
>> Op ma 5 nov. 2018 om 22:51 schreef Marius Bancila
>> <marius.bancila@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.
>>
>>
>>
>>
>

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/37a3ba2d-227d-0cc1-470f-05ec111872f0%40gmail.com.

.

------=_Part_2733_716105865.1541535194753
Content-Type: multipart/alternative;
 boundary="----=_Part_2734_1149121163.1541535194753"

------=_Part_2734_1149121163.1541535194753
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2018. november 6., kedd 8:51:52 UTC+1 id=C5=91pontban Olaf van der Spek a=
=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> AFAIK 2D graphics standardization was halted..=20
>

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

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

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5aa0d97c-6fae-4aac-b28a-1c8d5063f7e3%40isocpp.or=
g.

------=_Part_2734_1149121163.1541535194753
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2018. november 6., kedd 8:51:52 UTC+1 id=C5=91pontban Olaf=
 van der Spek a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">AFAIK 2D graphics standardization was halted..
<br></blockquote><div><br></div><div>It was, but not because lack of desire=
 for the feature. It was halted because the result this far is, while not e=
ven covering a lot of needed things, is huge in text and complexity.</div><=
div><br></div><div>There was an estimation that review of the material woul=
d have consumed the full capacity of the groups for the next 3 meetings (II=
RC), so effectively preventing progress on everything else on the table. <b=
r></div><div><br></div><div>OTOH in recent news we heard that enough people=
 are still interested so the related study group is getting revived. <br></=
div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5aa0d97c-6fae-4aac-b28a-1c8d5063f7e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5aa0d97c-6fae-4aac-b28a-1c8d5063f7e3=
%40isocpp.org</a>.<br />

------=_Part_2734_1149121163.1541535194753--

------=_Part_2733_716105865.1541535194753--

.

--000000000000f024fe057a061d79
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 6, 2018 at 5:23 AM Andrey Semashev <andrey.semashev@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?


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

--000000000000f024fe057a061d79
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, Nov 6, 2018 at 5:23 AM Andrey Semashev &lt;<a href=3D"mailto:andrey.semas=
hev@gmail.com">andrey.semashev@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">On 11/6/18 11:23 AM, Joel FALCOU wrote:<br>
&gt; If boost::uuid is enough and has a compelling argument, then maybe <br=
>
&gt; that&#39;s what need to be standardized.<br>
&gt; Boost provided maybe 80% of the new C++11 library, I can&#39;t see why=
 we <br>
&gt; can&#39;t continue pulling interesting piece of boost that<br>
&gt; shown efficiency and proper interface to solve a problem instead of <b=
r>
&gt; consuming more man-time.<br>
<br>
There are some downsides of Boost.UUID that I&#39;m not happy with and that=
 <br>
this proposal may fix. In particular, Boost.UUID mandates uuid internal <br=
>
implementation as an array of bytes, which prevents some optimizations. <br=
></blockquote><div><br></div><div>Sorry to ask you to repeat things that we=
&#39;ve mentioned before, but where do these optimizations happen?</div><di=
v>IIUC:</div><div><br></div><div>- =3D=3D and !=3D can be same speed regard=
less of order ? (ie you could compare it as int128 or whatever)</div><div>-=
 &lt; can&#39;t be fast if we use the ordering defined in the spec, but cou=
ld be if it was just &quot;some order&quot; (ie again, read the bytes as an=
 in128, ignoring byte order differences)</div><div>- we could have &lt; be =
slow, but offer a fast_uuid_order for use in maps?</div><div><br></div><div=
>Do I understand correctly?<br></div><br clear=3D"all"></div><br>-- <br><di=
v dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature">=
<div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu3zk6taGjbuB7bCumwU1RSOByij6mN=
kgSMi256QWgXcw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu3zk6taGjb=
uB7bCumwU1RSOByij6mNkgSMi256QWgXcw%40mail.gmail.com</a>.<br />

--000000000000f024fe057a061d79--

.

--000000000000b4b1f2057a074204
Content-Type: text/plain; charset="UTF-8"

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.

On Tue, Nov 6, 2018 at 9:59 PM Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Tue, Nov 6, 2018 at 5:23 AM Andrey Semashev <andrey.semashev@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?
>
>
> --
> 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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu3zk6taGjbuB7bCumwU1RSOByij6mNkgSMi256QWgXcw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUr0S%2BVKqEgj-DpLtT5v3TmQAjSnwFpPqCSf5A9VX_qFg%40mail.gmail.com.

--000000000000b4b1f2057a074204
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As for fast order: p0891r1 proposes std::default_order as =
a customization point for a total strong not-necessarily-semantic ordering =
on *your* type.<div><br></div><div>So you can have a semantic strong order =
on &lt;=C2=A0 and &lt;=3D&gt; and a fast order as default_order.</div><div>=
<br></div><div>Also, this is a shameless plug. It&#39;s about to be discuss=
ed and hopefully waved through to LWG.</div></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr">On Tue, Nov 6, 2018 at 9:59 PM Tony V E &lt;<a href=
=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=3D"gmail_=
quote"><div dir=3D"ltr">On Tue, Nov 6, 2018 at 5:23 AM Andrey Semashev &lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/=
6/18 11:23 AM, Joel FALCOU wrote:<br>
&gt; If boost::uuid is enough and has a compelling argument, then maybe <br=
>
&gt; that&#39;s what need to be standardized.<br>
&gt; Boost provided maybe 80% of the new C++11 library, I can&#39;t see why=
 we <br>
&gt; can&#39;t continue pulling interesting piece of boost that<br>
&gt; shown efficiency and proper interface to solve a problem instead of <b=
r>
&gt; consuming more man-time.<br>
<br>
There are some downsides of Boost.UUID that I&#39;m not happy with and that=
 <br>
this proposal may fix. In particular, Boost.UUID mandates uuid internal <br=
>
implementation as an array of bytes, which prevents some optimizations. <br=
></blockquote><div><br></div><div>Sorry to ask you to repeat things that we=
&#39;ve mentioned before, but where do these optimizations happen?</div><di=
v>IIUC:</div><div><br></div><div>- =3D=3D and !=3D can be same speed regard=
less of order ? (ie you could compare it as int128 or whatever)</div><div>-=
 &lt; can&#39;t be fast if we use the ordering defined in the spec, but cou=
ld be if it was just &quot;some order&quot; (ie again, read the bytes as an=
 in128, ignoring byte order differences)</div><div>- we could have &lt; be =
slow, but offer a fast_uuid_order for use in maps?</div><div><br></div><div=
>Do I understand correctly?<br></div><br clear=3D"all"></div><br>-- <br><di=
v dir=3D"ltr" class=3D"m_-2886567397993676959gmail_signature" data-smartmai=
l=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br=
></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu3zk6taGjbuB7bCumwU1RSOByij6mN=
kgSMi256QWgXcw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAOHCbiu3zk6taGjbuB7bCumwU1RSOByij6mNkgSMi256QWgXcw%40mail.gmail.com</=
a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUr0S%2BVKqEgj-DpLtT5v3TmQAjS=
nwFpPqCSf5A9VX_qFg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUr0S=
%2BVKqEgj-DpLtT5v3TmQAjSnwFpPqCSf5A9VX_qFg%40mail.gmail.com</a>.<br />

--000000000000b4b1f2057a074204--

.

On Wed, Nov 7, 2018 at 12:59 AM Tony V E <tvaneerd@gmail.com> wrote:
> On Tue, Nov 6, 2018 at 5:23 AM Andrey Semashev <andrey.semashev@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.

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Ayy5DO76TVqUVro%2BMr-66myoVTrRQTBZqHDudPSFoDJA%40mail.gmail.com.

.

On Wed, Nov 7, 2018 at 2:41 AM Andrey Semashev
<andrey.semashev@gmail.com> wrote:
>
> On Wed, Nov 7, 2018 at 12:59 AM Tony V E <tvaneerd@gmail.com> wrote:
> > On Tue, Nov 6, 2018 at 5:23 AM Andrey Semashev <andrey.semashev@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.

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.

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6CWtW81JXTrqNpN1Qqc6MfAhnazndUbAULd2UFnhQPX_g%40mail.gmail.com.

.