We are developing a compile-time random number generator.
In order to provide the seed, we coded a very simple constexpr
function that operates on the chars of __DATE__ and __TIME__.
However, I would like to improve this, e.g. by adding more accuracy.
This leads either to invent a long __EPOCH__-like macro with enough
precision (or a similar macro such as __MSECS_FROM_MIDNIGHT__) or a
built-in
compiler-implemented constexpr function, such as std::seed().

Any thoughts?

We will implement in (initially forked) gcc whatever looks best here.

Thanks,

    Daniel.

--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Tuesday 17 November 2015 17:08:35 dgutson . wrote:
> We are developing a compile-time random number generator.
> In order to provide the seed, we coded a very simple constexpr
> function that operates on the chars of __DATE__ and __TIME__.
> However, I would like to improve this, e.g. by adding more accuracy.
> This leads either to invent a long __EPOCH__-like macro with enough
> precision (or a similar macro such as __MSECS_FROM_MIDNIGHT__) or a
> built-in
> compiler-implemented constexpr function, such as std::seed().
>
> Any thoughts?
>
> We will implement in (initially forked) gcc whatever looks best here.

If you're forking GCC, you can add an intrinsic that can be called in that
constexpr context and returns a pseudo-random value of its own.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e01175e4d9e774e0524c26a83
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 17, 2015 at 12:08 PM, dgutson . <danielgutson@gmail.com> wrote:

> We are developing a compile-time random number generator.
> In order to provide the seed, we coded a very simple constexpr
> function that operates on the chars of __DATE__ and __TIME__.
> However, I would like to improve this, e.g. by adding more accuracy.
> This leads either to invent a long __EPOCH__-like macro with enough
> precision (or a similar macro such as __MSECS_FROM_MIDNIGHT__) or a
> built-in
> compiler-implemented constexpr function, such as std::seed().


Compile-time random sounds pretty cool. I can think of a couple of uses,
but I'm curious what your primary uses are.

Regarding a compile-implemented constexpr function that produces a unique
seed, I think you'd very quickly run into ODR issues unless you guaranteed
that all translation units produced the same seed (i.e. you'd probably have
to seed your seed via a macro or something). Have you considered just
providing the seed directly from the outside via a compiler option, such as
-D, and generating that seed via your build system? I realize that this is
outside of the realm of the standard, but it's probably worth considering
anyway. The facility would likely be just as useful in practice, unless I'm
missing something.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01175e4d9e774e0524c26a83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 17, 2015 at 12:08 PM, dgutson . <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">We are developing a comp=
ile-time random number generator.<br>
In order to provide the seed, we coded a very simple constexpr<br>
function that operates on the chars of __DATE__ and __TIME__.<br>
However, I would like to improve this, e.g. by adding more accuracy.<br>
This leads either to invent a long __EPOCH__-like macro with enough<br>
precision (or a similar macro such as __MSECS_FROM_MIDNIGHT__) or a<br>
built-in<br>
compiler-implemented constexpr function, such as std::seed().</blockquote><=
div><br></div><div>Compile-time random sounds pretty cool. I can think of a=
 couple of uses, but I&#39;m curious what your primary uses are.</div><div>=
<br></div><div>Regarding a compile-implemented constexpr function that prod=
uces a unique seed, I think you&#39;d very quickly run into ODR issues unle=
ss you guaranteed that all translation units produced the same seed (i.e. y=
ou&#39;d probably have to seed your seed via a macro or something). Have yo=
u considered just providing the seed directly from the outside via a compil=
er option, such as -D, and generating that seed via your build system? I re=
alize that this is outside of the realm of the standard, but it&#39;s proba=
bly worth considering anyway. The facility would likely be just as useful i=
n practice, unless I&#39;m missing something.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01175e4d9e774e0524c26a83--

.

On Tue, Nov 17, 2015 at 5:23 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Tuesday 17 November 2015 17:08:35 dgutson . wrote:
>> We are developing a compile-time random number generator.
>> In order to provide the seed, we coded a very simple constexpr
>> function that operates on the chars of __DATE__ and __TIME__.
>> However, I would like to improve this, e.g. by adding more accuracy.
>> This leads either to invent a long __EPOCH__-like macro with enough
>> precision (or a similar macro such as __MSECS_FROM_MIDNIGHT__) or a
>> built-in
>> compiler-implemented constexpr function, such as std::seed().
>>
>> Any thoughts?
>>
>> We will implement in (initially forked) gcc whatever looks best here.
>
> If you're forking GCC, you can add an intrinsic that can be called in tha=
t
> constexpr context and returns a pseudo-random value of its own.

Yes, that's one of the alternatives we are considering as the
"compiler magic" version,
though I'd like to see the frontend stadard first.

>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Tue, Nov 17, 2015 at 5:31 PM, 'Matt Calabrese' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
> On Tue, Nov 17, 2015 at 12:08 PM, dgutson . <danielgutson@gmail.com> wrot=
e:
>>
>> We are developing a compile-time random number generator.
>> In order to provide the seed, we coded a very simple constexpr
>> function that operates on the chars of __DATE__ and __TIME__.
>> However, I would like to improve this, e.g. by adding more accuracy.
>> This leads either to invent a long __EPOCH__-like macro with enough
>> precision (or a similar macro such as __MSECS_FROM_MIDNIGHT__) or a
>> built-in
>> compiler-implemented constexpr function, such as std::seed().
>
>
> Compile-time random sounds pretty cool. I can think of a couple of uses, =
but
> I'm curious what your primary uses are.

Unfortunately I cannot provide much details; one use is cryptography
(so each binary is released with some uniqueness).
Another potential use is the pivot selection of quicksort, though we
are not using this.

>
> Regarding a compile-implemented constexpr function that produces a unique
> seed, I think you'd very quickly run into ODR issues unless you guarantee=
d
> that all translation units produced the same seed (i.e. you'd probably ha=
ve
> to seed your seed via a macro or something). Have you considered just
> providing the seed directly from the outside via a compiler option, such =
as
> -D, and generating that seed via your build system? I realize that this i=
s
> outside of the realm of the standard, but it's probably worth considering
> anyway. The facility would likely be just as useful in practice, unless I=
'm
> missing something.

Despite I'm looking for a potential proposal, the -D idea didn't come
to my mind, thanks, we are
actually thinking in deep gcc support which could be tested with its
native test framework (dejaGNU),
so a new macro or built-in is the way to go.

>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Tuesday 17 November 2015 17:40:59 dgutson . wrote:
> > If you're forking GCC, you can add an intrinsic that can be called in that
> > constexpr context and returns a pseudo-random value of its own.
>
> Yes, that's one of the alternatives we are considering as the
> "compiler magic" version,
> though I'd like to see the frontend stadard first.

I don't think this could be standardised. We want reliable builds.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b6249962ef7500524c4b35c
Content-Type: text/plain; charset=UTF-8

On 17 November 2015 at 16:59, Thiago Macieira <thiago@macieira.org> wrote:

> On Tuesday 17 November 2015 17:40:59 dgutson . wrote:
> > > If you're forking GCC, you can add an intrinsic that can be called in
> that
> > > constexpr context and returns a pseudo-random value of its own.
> >
> > Yes, that's one of the alternatives we are considering as the
> > "compiler magic" version,
> > though I'd like to see the frontend stadard first.
>
> I don't think this could be standardised. We want reliable builds.
>

I'm guessing you meant repeatable, not reliable.  If so, I agree.  If not,
please elaborate.

I'm also weary about the cryptographic applications of such a
function/macro, as that is usually based on keeping something secret.  And
if Daniel cannot talk about it, it becomes that much harder to get support
for the feature.

As for the pivot selection of quicksort, why does having a *constexpr* seed
generator particularly help (I suppose you could get a tiny bit of inlining
performance when applying it to nearly sorted data, but I'd like to see
benchmarks before drawing any conclusions)?

--
 Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>>
+1-847-691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b6249962ef7500524c4b35c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 17 November 2015 at 16:59, Thiago Macieira <span dir=3D=
"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@m=
acieira.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tuesday=
 17 November 2015 17:40:59 dgutson . wrote:<br>
&gt; &gt; If you&#39;re forking GCC, you can add an intrinsic that can be c=
alled in that<br>
&gt; &gt; constexpr context and returns a pseudo-random value of its own.<b=
r>
&gt;<br>
&gt; Yes, that&#39;s one of the alternatives we are considering as the<br>
&gt; &quot;compiler magic&quot; version,<br>
&gt; though I&#39;d like to see the frontend stadard first.<br>
<br>
</span>I don&#39;t think this could be standardised. We want reliable build=
s.<br></blockquote><div><br></div><div>I&#39;m guessing you meant repeatabl=
e, not reliable.=C2=A0 If so, I agree.=C2=A0 If not, please elaborate.</div=
><div><br></div><div>I&#39;m also weary about the cryptographic application=
s of such a function/macro, as that is usually based on keeping something s=
ecret.=C2=A0 And if Daniel cannot talk about it, it becomes that much harde=
r to get support for the feature.</div><div><br></div><div>As for the pivot=
 selection of quicksort, why does having a <i>constexpr</i> seed generator =
particularly help (I suppose you could get a tiny bit of inlining performan=
ce when applying it to nearly sorted data, but I&#39;d like to see benchmar=
ks before drawing any conclusions)?<br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">=C2=A0Nevin &quot;:-)&quot;=
 Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@cplusplusguy.com</a>&gt;=C2=A0 +1-847-691-1404<br></div></di=
v>
</div></div></div>
</div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b6249962ef7500524c4b35c--

.

--001a1142789e7fa4730524c553ba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 17/11/2015 20:15, "Nevin Liber" <nevin@cplusplusguy.com> escribi=C3=B3:
>
> On 17 November 2015 at 16:59, Thiago Macieira <thiago@macieira.org> wrote=
:
>>
>> On Tuesday 17 November 2015 17:40:59 dgutson . wrote:
>> > > If you're forking GCC, you can add an intrinsic that can be called
in that
>> > > constexpr context and returns a pseudo-random value of its own.
>> >
>> > Yes, that's one of the alternatives we are considering as the
>> > "compiler magic" version,
>> > though I'd like to see the frontend stadard first.
>>
>> I don't think this could be standardised. We want reliable builds.
>
>
> I'm guessing you meant repeatable, not reliable.  If so, I agree.  If
not, please elaborate.

What's the std definition of 'repeatable'? Does the std require to generate
always the same binary?

>
> I'm also weary about the cryptographic applications of such a
function/macro, as that is usually based on keeping something secret.  And
if Daniel cannot talk about it, it becomes that much harder to get support
for the feature.

Ok I'll try. Let's suppose we have a production line for some mil
application where for security reasons each binary has to be released in a
way that if it gets hacked, other binaries (produced with the same code)
don't get hacked by the same codes.

>
> As for the pivot selection of quicksort, why does having a constexpr seed
generator particularly help (I suppose you could get a tiny bit of inlining
performance when applying it to nearly sorted data, but I'd like to see
benchmarks before drawing any conclusions)?

Because we are already able to have associative containers that are stored
in ROM, which nontrivial constructors are executed in constexpr time, and
some hashing functions that are also executed in constexpr contexts which
also require RNG. I already started a thread in this list a couple of
months ago where people suggested that current STL containers should be ROM
friendly rather than a brand new category (such as static_unordered_map).
We are already there but this will be a very lengthy paper.

>
> --
>  Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com>  +1-847-691-1404
>
> --
>
> ---
> 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.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a1142789e7fa4730524c553ba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
El 17/11/2015 20:15, &quot;Nevin Liber&quot; &lt;<a href=3D"mailto:nevin@cp=
lusplusguy.com">nevin@cplusplusguy.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On 17 November 2015 at 16:59, Thiago Macieira &lt;<a href=3D"mailto:th=
iago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday 17 November 2015 17:40:59 dgutson . wrote:<br>
&gt;&gt; &gt; &gt; If you&#39;re forking GCC, you can add an intrinsic that=
 can be called in that<br>
&gt;&gt; &gt; &gt; constexpr context and returns a pseudo-random value of i=
ts own.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yes, that&#39;s one of the alternatives we are considering as=
 the<br>
&gt;&gt; &gt; &quot;compiler magic&quot; version,<br>
&gt;&gt; &gt; though I&#39;d like to see the frontend stadard first.<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t think this could be standardised. We want reliable bui=
lds.<br>
&gt;<br>
&gt;<br>
&gt; I&#39;m guessing you meant repeatable, not reliable.=C2=A0 If so, I ag=
ree.=C2=A0 If not, please elaborate.</p>
<p dir=3D"ltr">What&#39;s the std definition of &#39;repeatable&#39;? Does =
the std require to generate always the same binary?</p>
<p dir=3D"ltr">&gt;<br>
&gt; I&#39;m also weary about the cryptographic applications of such a func=
tion/macro, as that is usually based on keeping something secret.=C2=A0 And=
 if Daniel cannot talk about it, it becomes that much harder to get support=
 for the feature.</p>
<p dir=3D"ltr">Ok I&#39;ll try. Let&#39;s suppose we have a production line=
 for some mil application where for security reasons each binary has to be =
released in a way that if it gets hacked, other binaries (produced with the=
 same code) don&#39;t get hacked by the same codes.</p>
<p dir=3D"ltr">&gt;<br>
&gt; As for the pivot selection of quicksort, why does having a constexpr s=
eed generator particularly help (I suppose you could get a tiny bit of inli=
ning performance when applying it to nearly sorted data, but I&#39;d like t=
o see benchmarks before drawing any conclusions)?</p>
<p dir=3D"ltr">Because we are already able to have associative containers t=
hat are stored in ROM, which nontrivial constructors are executed in conste=
xpr time, and some hashing functions that are also executed in constexpr co=
ntexts which also require RNG. I already started a thread in this list a co=
uple of months ago where people suggested that current STL containers shoul=
d be ROM friendly rather than a brand new category (such as static_unordere=
d_map). We are already there but this will be a very lengthy paper.</p>
<p dir=3D"ltr">&gt;<br>
&gt; -- <br>
&gt; =C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@cplusplusguy.com">nevin@cplusplusguy.com</a>&gt;=C2=A0 +1-847-691-1404=
<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1142789e7fa4730524c553ba--

.

On Tuesday 17 November 2015 21:00:10 dgutson . wrote:
> >> I don't think this could be standardised. We want reliable builds.
> >
> > I'm guessing you meant repeatable, not reliable.  If so, I agree.  If
> > not, please elaborate.

Yes, I meant repeatable.

> What's the std definition of 'repeatable'? Does the std require to generate
> always the same binary?

The same output is produced with the same inputs (where that includes the
compiler itself and any switches you may toggle). There's also a reason why
GCC added -Wdate-time to warn about the use of __DATE__ and __TIME__, as those
produce non-repeatable builds.

The standard doesn't require that, of course. But I think it's the objective
of compiler writers. Repeatable builds allow for verification against
compromising of the binaries. The reason why -Wdate-time was actually added to
GCC was because some Linux distributions (notably those using OBS) compare
binaries to see whether an update was required.

> > I'm also weary about the cryptographic applications of such a
> > function/macro, as that is usually based on keeping something secret.  And
> > if Daniel cannot talk about it, it becomes that much harder to get support
> > for the feature.
>
> Ok I'll try. Let's suppose we have a production line for some mil
> application where for security reasons each binary has to be released in a
> way that if it gets hacked, other binaries (produced with the same code)
> don't get hacked by the same codes.

Then you'd have some expert tools implement that.

If randomising the layout of the program is a good prevention method (and it
is), you probably want to implement that in the compiler so it rearranges the
code and possibly adds a slight disturbance to the stack frame sizes.

A random seed available to the source code is not that really useful, IMHO.

> Because we are already able to have associative containers that are stored
> in ROM, which nontrivial constructors are executed in constexpr time, and
> some hashing functions that are also executed in constexpr contexts which
> also require RNG.

PRNG-based hashing functions are a good idea, but you usually want the hash
seed to be computed at runtime, not at compile time. That's also the same
principle as ASLR found on modern OSes.

I get it that you have a static (ROM) hashing table, but it's very unlikely
that you implemented it with constexpr. The most common case is that you have
a code generation tool that laid the hashing table out for you (and you should
consider a perfect hashing algorithm instead, like gperf). Either way, either
this tool generated the random seed or one was given to it. Moreover, you need
the same seed in all translation units that access that hash, which means a
buildsystem option, not a compiler one.

Unless you saved the seed in the hashing table, which probably defeats your
purpose in the first place.

> I already started a thread in this list a couple of
> months ago where people suggested that current STL containers should be ROM
> friendly rather than a brand new category (such as static_unordered_map).
> We are already there but this will be a very lengthy paper.

ROM-friendly I agree. But in case of unordered_map, I think a perfect hashing
is a superior solution.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_3786_1792743194.1447807834167
Content-Type: multipart/alternative;
 boundary="----=_Part_3787_1494044414.1447807834168"

------=_Part_3787_1494044414.1447807834168
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, November 17, 2015 at 12:31:56 PM UTC-8, Matt Calabrese wrote:
>
> On Tue, Nov 17, 2015 at 12:08 PM, dgutson . <daniel...@gmail.com=20
> <javascript:>> wrote:
>
>> We are developing a compile-time random number generator.
>> In order to provide the seed, we coded a very simple constexpr
>> function that operates on the chars of __DATE__ and __TIME__.
>> However, I would like to improve this, e.g. by adding more accuracy.
>> This leads either to invent a long __EPOCH__-like macro with enough
>> precision (or a similar macro such as __MSECS_FROM_MIDNIGHT__) or a
>> built-in compiler-implemented constexpr function, such as std::seed().
>
>
I would guess that anybody who expects the compiler to provide them with an=
=20
*accurate* value for the current timestamp "is, of course, in a state of=20
sin."
We've got timezones, Daylight Savings, leap seconds, clock drift,=20
platform-specific resolution... These are problems worth tackling in the=20
Standard Library, but not in the core language. The core language, ever=20
since 1989, has punted on the whole question by providing __DATE__ and=20
__TIME__ only in a really unconsumable format: strings with=20
implementation-defined contents.

Apple has gone so far as to build a macro "__CF_COMPILE_DAY_OF_EPOCH__"=20
that constructs the number of days since 2001-01-01; you could imagine=20
extending this approach to create __CF_COMPILE_SECONDS_OF_UNIX_EPOCH__, but=
=20
of course getting the current *millisecond* isn't possible without compiler=
=20
cooperation.
http://www.opensource.apple.com/source/CF/CF-635.19/CFInternal.h?txt
=20

> Compile-time random sounds pretty cool. I can think of a couple of uses,=
=20
> but I'm curious what your primary uses are.
>
> Regarding a compile-implemented constexpr function that produces a unique=
=20
> seed, I think you'd very quickly run into ODR issues unless you guarantee=
d=20
> that all translation units produced the same seed (i.e. you'd probably ha=
ve=20
> to seed your seed via a macro or something). Have you considered just=20
> providing the seed directly from the outside via a compiler option, such =
as=20
> -D, and generating that seed via your build system? I realize that this i=
s=20
> outside of the realm of the standard, but it's probably worth considering=
=20
> anyway. The facility would likely be just as useful in practice, unless I=
'm=20
> missing something.
>

In order of "plausibility" (implementability, aesthetics, simplicity), if I=
=20
were you I'd be looking at:
(A) Just generate a seed in the build system and pass it in with -D.
(B) Implement a (cryptographic?) hash function H as a macro, metafunction,=
=20
or constexpr function, and use H(__COUNTER__) in your source code.
(C) Implement __RANDOM__, or __builtin_random_constant(), or some such. I=
=20
would strongly advise against making __builtin_rand() work in constant=20
contexts, because that would just be crazy surprising.
(D) Implement __EPOCH_MILLISECONDS__ or some such. Notice that there are=20
lots and lots of people asking for (the semantics, not necessarily the=20
name) __EPOCH_SECONDS__ on StackOverflow. Also notice that GNU provides a=
=20
builtin macro named __TIMESTAMP__ that holds a string representation of the=
=20
last modification time of the current source file (as opposed to the=20
__TIME__ at which it was compiled). So that name is taken.
(E) Implement some kind of built-in constexpr PRNG along the lines of your=
=20
first post. :)

Notice that (A) and (B) and (C) all solve different problems:
(A) solves the problem of getting a single optionally-reproducible random=
=20
number into a single place in the code.
(B) solves the problem of getting a sequence of reproducible random numbers=
=20
into arbitrarily many places in the code. (Or hash __TIME__ into there too,=
=20
for optional non-reproducibility as long as you're not compiling multiple=
=20
times per second.)
(C) and (E) solve the problem of getting a sequence of non-reproducible=20
random numbers into arbitrarily many places in the code.
(D) solves the problem of injecting non-reproducibility into (B) for those=
=20
who like to compile multiple times per second.

So the most "plausible" feature requests I hear here are:

__COUNTER__, because it's already vendor-standard and just needs a proposal=
=20
written as far as I'm aware
__RANDOM__, for people who either need a stream of pseudorandom numbers and=
=20
don't want to bother with HASH(__COUNTER__), or who need a single=20
non-reproducible random number
__EPOCH_SECONDS__, because it's in great demand

I don't like the idea of __EPOCH_MILLISECONDS__, because it doesn't *really=
*=20
give the programmer any useful information; it's effectively=20
indistinguishable from

constexpr int millis =3D __RANDOM__;
#define EPOCH_MILLISECONDS (__EPOCH_SECONDS__*1000 + millis)

I don't think it makes sense to describe a constexpr random-number=20
function: that would be a function that gives a different result every time=
=20
it's called, but (being constexpr) is guaranteed to give the same result=20
every time it's called?

I do think that __RANDOM__ would solve your problem of "seed a constexpr=20
PRNG", although it might not solve other related problems of yours or=20
anyone else's.
I'd certainly feel awful if __RANDOM__ somehow got standardized ahead of=20
__COUNTER__. :P

=E2=80=93Arthur

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_3787_1494044414.1447807834168
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, November 17, 2015 at 12:31:56 PM UTC-8, Matt Calabrese wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Tue, Nov 17, 2015 at 12:08 PM, dgutson . <span dir=3D"l=
tr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
rRAQB3hpBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">daniel...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">We are developing a compile-time random number generator.<br>
In order to provide the seed, we coded a very simple constexpr<br>
function that operates on the chars of __DATE__ and __TIME__.<br>
However, I would like to improve this, e.g. by adding more accuracy.<br>
This leads either to invent a long __EPOCH__-like macro with enough<br>
precision (or a similar macro such as __MSECS_FROM_MIDNIGHT__) or a<br>
built-in=C2=A0compiler-implemented constexpr function, such as std::seed().=
</blockquote></div></div></div></blockquote><div><br></div><div>I would gue=
ss that anybody who expects the compiler to provide them with an <i>accurat=
e</i> value for the current timestamp &quot;is, of course, in a state of si=
n.&quot;</div><div>We&#39;ve got timezones, Daylight Savings, leap seconds,=
 clock drift, platform-specific resolution... These are problems worth tack=
ling in the Standard Library, but not in the core language. The core langua=
ge, ever since 1989, has punted on the whole question by providing __DATE__=
 and __TIME__ only in a really unconsumable format: strings with implementa=
tion-defined contents.</div><div><br></div><div><div>Apple has gone so far =
as to build a macro &quot;<span style=3D"color: rgb(0, 0, 0); white-space: =
pre-wrap;">__CF_COMPILE_DAY_OF_EPOCH__&quot; that constructs the number of =
days since 2001-01-01; you could imagine extending this approach to create =
 __CF_COMPILE_SECONDS_OF_UNIX_EPOCH__, but of course getting the current <i=
>millisecond</i> isn&#39;t possible without compiler cooperation.</span></d=
iv><div><a href=3D"http://www.opensource.apple.com/source/CF/CF-635.19/CFIn=
ternal.h?txt">http://www.opensource.apple.com/source/CF/CF-635.19/CFInterna=
l.h?txt</a></div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Compile-time ran=
dom sounds pretty cool. I can think of a couple of uses, but I&#39;m curiou=
s what your primary uses are.<br></div><div><br></div><div>Regarding a comp=
ile-implemented constexpr function that produces a unique seed, I think you=
&#39;d very quickly run into ODR issues unless you guaranteed that all tran=
slation units produced the same seed (i.e. you&#39;d probably have to seed =
your seed via a macro or something). Have you considered just providing the=
 seed directly from the outside via a compiler option, such as -D, and gene=
rating that seed via your build system? I realize that this is outside of t=
he realm of the standard, but it&#39;s probably worth considering anyway. T=
he facility would likely be just as useful in practice, unless I&#39;m miss=
ing something.</div></div></div></blockquote><div><br></div><div>In order o=
f &quot;plausibility&quot; (implementability, aesthetics, simplicity), if I=
 were you I&#39;d be looking at:</div><div>(A) Just generate a seed in the =
build system and pass it in with -D.</div><div>(B) Implement a (cryptograph=
ic?) hash function H as a macro, metafunction, or constexpr function, and u=
se H(__COUNTER__) in your source code.</div><div>(C) Implement __RANDOM__, =
or __builtin_random_constant(), or some such. I would strongly advise again=
st making __builtin_rand() work in constant contexts, because that would ju=
st be crazy surprising.</div><div>(D) Implement __EPOCH_MILLISECONDS__ or s=
ome such. Notice that there are lots and lots of people asking for (the sem=
antics, not necessarily the name) __EPOCH_SECONDS__ on StackOverflow. Also =
notice that GNU provides a builtin macro named __TIMESTAMP__ that holds a s=
tring representation of the last modification time of the current source fi=
le (as opposed to the __TIME__ at which it was compiled). So that name is t=
aken.</div><div>(E) Implement some kind of built-in constexpr PRNG along th=
e lines of your first post. :)</div><div><br></div><div>Notice that (A) and=
 (B) and (C) all solve different problems:</div><div>(A) solves the problem=
 of getting a single optionally-reproducible random number into a single pl=
ace in the code.</div><div>(B) solves the problem of getting a sequence of =
reproducible random numbers into arbitrarily many places in the code. (Or h=
ash __TIME__ into there too, for optional non-reproducibility as long as yo=
u&#39;re not compiling multiple times per second.)</div><div>(C) and (E) so=
lve the problem of getting a sequence of non-reproducible random numbers in=
to arbitrarily many places in the code.</div><div>(D) solves the problem of=
 injecting non-reproducibility into (B) for those who like to compile multi=
ple times per second.</div><div><br></div><div>So the most &quot;plausible&=
quot; feature requests I hear here are:</div><div><br></div><div>__COUNTER_=
_, because it&#39;s already vendor-standard and just needs a proposal writt=
en as far as I&#39;m aware</div><div>__RANDOM__, for people who either need=
 a stream of pseudorandom numbers and don&#39;t want to bother with HASH(__=
COUNTER__), or who need a single non-reproducible random number</div><div>_=
_EPOCH_SECONDS__, because it&#39;s in great demand</div><div><br></div><div=
>I don&#39;t like the idea of __EPOCH_MILLISECONDS__, because it doesn&#39;=
t <i>really</i> give the programmer any useful information; it&#39;s effect=
ively indistinguishable from</div><div><br></div><div>constexpr int millis =
=3D __RANDOM__;</div><div>#define EPOCH_MILLISECONDS (__EPOCH_SECONDS__*100=
0 + millis)</div><div><br></div><div>I don&#39;t think it makes sense to de=
scribe a constexpr random-number function: that would be a function that gi=
ves a different result every time it&#39;s called, but (being constexpr) is=
 guaranteed to give the same result every time it&#39;s called?</div><div><=
br></div><div>I do think that __RANDOM__ would solve your problem of &quot;=
seed a constexpr PRNG&quot;, although it might not solve other related prob=
lems of yours or anyone else&#39;s.</div><div>I&#39;d certainly feel awful =
if __RANDOM__ somehow got standardized ahead of __COUNTER__. :P</div><div><=
br></div><div>=E2=80=93Arthur</div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3787_1494044414.1447807834168--
------=_Part_3786_1792743194.1447807834167--

.

--001a1141cf8ca6b7c20524c69530
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 17, 2015 at 2:44 PM, dgutson . <danielgutson@gmail.com> wrote:

> Despite I'm looking for a potential proposal, the -D idea didn't come
> to my mind, thanks, we are
> actually thinking in deep gcc support which could be tested with its
> native test framework (dejaGNU),
> so a new macro or built-in is the way to go.
>

Despite of the `constexpr` part, std::seed() is still worthy to add.  It's a
separation of concerns, and may be beneficial in terms of portability,
quality, and/or performance (comparing to random_device).

About the `constexpr` part, my biggest concern is the quality of the
seed... I heard epoch, time, etc., but those are all of low quality.  The
only trustful way came into my mind is that the compiler links to C++
standard library and calls std::seed(), which may be implemented using
getentropy(2)/getrandom(2)/RDSEED, etc. to substitute std::seed upon
constexpr is requested.  Anyhow, my suggestion is: forget about
what the seed actually is when you proposing this.

A side note: it might be worthy to allow such a utility to generate seeds
of different widths, like 32/64 bits.  The interface may be seed<unsigned>
or something.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1141cf8ca6b7c20524c69530
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Nov 17, 2015 at 2:44 PM, dgutson . <span dir=3D"ltr">&lt;<a href=3D=
"mailto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":1lv" clas=
s=3D"a3s" style=3D"overflow:hidden">Despite I&#39;m looking for a potential=
 proposal, the -D idea didn&#39;t come<br>
to my mind, thanks, we are<br>
actually thinking in deep gcc support which could be tested with its<br>
native test framework (dejaGNU),<br>
so a new macro or built-in is the way to go.</div></blockquote></div><br></=
div><div class=3D"gmail_extra">Despite of the `constexpr` part, std::seed()=
 is still worthy to add.=C2=A0 It&#39;s a<br></div><div class=3D"gmail_extr=
a">separation of concerns, and may be beneficial in terms of portability,<b=
r></div><div class=3D"gmail_extra">quality, and/or performance (comparing t=
o random_device).<br><br></div><div class=3D"gmail_extra">About the `conste=
xpr` part, my biggest concern is the quality of the<br></div><div class=3D"=
gmail_extra">seed... I heard epoch, time, etc., but those are all of low qu=
ality.=C2=A0 The<br></div><div class=3D"gmail_extra">only trustful way came=
 into my mind is that the compiler links to C++<br></div><div class=3D"gmai=
l_extra">standard library and calls std::seed(), which may be implemented u=
sing<br>getentropy(2)/getrandom(2)/RDSEED, etc. to substitute std::seed upo=
n<br></div><div class=3D"gmail_extra">constexpr is requested.=C2=A0 Anyhow,=
 my suggestion is: forget about<br></div><div class=3D"gmail_extra">what th=
e seed actually is when you proposing this.<br><br></div><div class=3D"gmai=
l_extra">A side note: it might be worthy to allow such a utility to generat=
e seeds<br></div><div class=3D"gmail_extra">of different widths, like 32/64=
 bits.=C2=A0 The interface may be seed&lt;unsigned&gt;<br></div><div class=
=3D"gmail_extra">or something.<br></div><div class=3D"gmail_extra"><br>-- <=
br><div class=3D"gmail_signature">Zhihao Yuan, ID lichray<br>The best way t=
o predict the future is to invent it.<br>__________________________________=
_________________<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_=
blank">http://bit.ly/blog4bsd</a></div>
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1141cf8ca6b7c20524c69530--

.

On Tuesday 17 November 2015 19:30:16 Zhihao Yuan wrote:
> On Tue, Nov 17, 2015 at 2:44 PM, dgutson . <danielgutson@gmail.com> wrote:
> > Despite I'm looking for a potential proposal, the -D idea didn't come
> > to my mind, thanks, we are
> > actually thinking in deep gcc support which could be tested with its
> > native test framework (dejaGNU),
> > so a new macro or built-in is the way to go.
>
> Despite of the `constexpr` part, std::seed() is still worthy to add.  It's a
> separation of concerns, and may be beneficial in terms of portability,
> quality, and/or performance (comparing to random_device).

What would std::seed() do that std::random_device() cannot do?

> About the `constexpr` part, my biggest concern is the quality of the
> seed... I heard epoch, time, etc., but those are all of low quality.  The
> only trustful way came into my mind is that the compiler links to C++
> standard library and calls std::seed(), which may be implemented using
> getentropy(2)/getrandom(2)/RDSEED, etc. to substitute std::seed upon
> constexpr is requested.  Anyhow, my suggestion is: forget about
> what the seed actually is when you proposing this.

> A side note: it might be worthy to allow such a utility to generate seeds
> of different widths, like 32/64 bits.  The interface may be seed<unsigned>
> or something.

std::random_device can do that.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tuesday 17 November 2015 16:50:34 Arthur O'Dwyer wrote:
> I don't think it makes sense to describe a constexpr random-number
> function: that would be a function that gives a different result every time
> it's called, but (being constexpr) is guaranteed to give the same result
> every time it's called?
>
> I do think that __RANDOM__ would solve your problem of "seed a constexpr
> PRNG", although it might not solve other related problems of yours or
> anyone else's.
> I'd certainly feel awful if __RANDOM__ somehow got standardized ahead of
> __COUNTER__.

Note that constexpr is implicitly inline and must be present in all
translation units that use it. And by ODR, it must have the same definition
and value.

So if you were to do:

 constexpr int seed = __RANDOM__;

and include that header from two source files, you'd violate ODR. The same
would go for __TIME__ or __EPOCH_SECONDS__ because different translation units
may be compiled at different times. Even __COUNTER__ is a bad idea because it
might have been used in another header.

At best, you could do in a header file:

 extern const MyRomHash hash_in_rom;

which, as you can see, has no constexpr and, if you don't write the
initialisation code properly, could end up initialised dynamically (not in
ROM).

The proper way of doing this would be to access via a function that returns
the pointer to the data (a possibly unnecessary indirection).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tuesday 17 November 2015 19:47:03 Thiago Macieira wrote:
> At best, you could do in a header file:
>
>         extern const MyRomHash hash_in_rom;
>
> which, as you can see, has no constexpr and, if you don't write the
> initialisation code properly, could end up initialised dynamically (not in
> ROM).

I take this part back. This is allowed:

 extern const MyRomHash hash_in_rom;
 constexpr MyRomHash hash_in_rom = make_hash();

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4186_1847812464.1447841119110
Content-Type: multipart/alternative;
 boundary="----=_Part_4187_2124756680.1447841119110"

------=_Part_4187_2124756680.1447841119110
Content-Type: text/plain; charset=UTF-8



On Tuesday, November 17, 2015 at 10:47:08 PM UTC-5, Thiago Macieira wrote:
>
>
> So if you were to do:
>
>         constexpr int seed = __RANDOM__;
>
> and include that header from two source files, you'd violate ODR.


Not necessarily. Assuming that it's at namespace scope, 'seed' defaults to
internal linkage.

Of course, ODR means that you can't really use it in many contexts.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4187_2124756680.1447841119110
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, November 17, 2015 at 10:47:08 PM UTC-5=
, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>So=
 if you were to do:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0constexpr int seed =3D =
__RANDOM__;
<br>
<br>and include that header from two source files, you&#39;d violate ODR.</=
blockquote><div><br></div><div>Not necessarily. Assuming that it&#39;s at n=
amespace scope, &#39;seed&#39; defaults to internal linkage.</div><div><br>=
</div><div>Of course, ODR means that you can&#39;t really use it in many co=
ntexts.</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4187_2124756680.1447841119110--
------=_Part_4186_1847812464.1447841119110--

.

On Tue, Nov 17, 2015 at 9:36 PM, Thiago Macieira <thiago@macieira.org> wrote:
>
>> Despite of the `constexpr` part, std::seed() is still worthy to add.  It's a
>> separation of concerns, and may be beneficial in terms of portability,
>> quality, and/or performance (comparing to random_device).
>
> What would std::seed() do that std::random_device() cannot do?

We haven't decide what std::seed() gives so I say it's a separation
of concerns.  There are multiple questions we can raise here, from
"can random_device{}() be portable usable for seeding?" (non-
predictable is not portably guaranteed) to "how high the entropy
given by random_device{}() is?" (not required to give full entropy),
etc., and you can see that the directions are different...

>> A side note: it might be worthy to allow such a utility to generate seeds
>> of different widths, like 32/64 bits.  The interface may be seed<unsigned>
>> or something.
>
> std::random_device can do that.

No, it cannot.  Its `result_type` is fixed to `unsigned int`.

Rather than seed<T>, another technique I previously used is to
return an empty object, with a templated conversion operator
to IntT, so that .seed(Some-int-type) will receive the seeds of
the right width if invoked with .seed(get_seed()).

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.