Topic: static_read


Author: ma.kalbfuss@web.de
Date: Sat, 20 May 2017 11:32:28 -0700 (PDT)
Raw View
------=_Part_1942_834815519.1495305148646
Content-Type: multipart/alternative;
 boundary="----=_Part_1943_1156455621.1495305148646"

------=_Part_1943_1156455621.1495305148646
Content-Type: text/plain; charset="UTF-8"

Hallo guys,

my idea is about the possibility to read in file at compile time using
static_read.
The file content ist returned as a string literal, which can be processed
afterwards.
Important is, that the the returned string literal is constexpr. You can
use it as
template parameter or inside constexpr functions.
What is it good for?

Think of an BNF or EBNF grammer described in a external file. This file is
transformed into a string literal. The string literal could be transformed
into a parser
at compile time, using a contexpr function.

This is not limited to BNF or EBNF. It works for all kind of domain
specific languages.
Another usage are data files. ll kind of xml files could be transformed
to C++ Data structures, for example.

MFG

Martin

--
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/ebacba3e-24df-4804-8147-548600264697%40isocpp.org.

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

<div dir=3D"ltr">Hallo guys,<br><br>my idea is about the possibility to rea=
d in file at compile time using static_read.<br>The file content ist return=
ed as a string literal, which can be processed afterwards.<br>Important is,=
 that the the returned string literal is constexpr. You can use it as<br>te=
mplate parameter or inside constexpr functions.<br>What is it good for?<br>=
<br>Think of an BNF or EBNF grammer described in a external file. This file=
 is<br>transformed into a string literal. The string literal could be trans=
formed into a parser<br>at compile time, using a contexpr function.<br><br>=
This is not limited to BNF or EBNF. It works for all kind of domain specifi=
c languages.<br>Another usage are data files. ll kind of xml files could be=
 transformed<br>to C++ Data structures, for example.<br><br>MFG<br><br>Mart=
in<br></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/ebacba3e-24df-4804-8147-548600264697%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ebacba3e-24df-4804-8147-548600264697=
%40isocpp.org</a>.<br />

------=_Part_1943_1156455621.1495305148646--

------=_Part_1942_834815519.1495305148646--

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 20 May 2017 12:30:46 -0700
Raw View
On s=C3=A1bado, 20 de maio de 2017 11:32:28 PDT ma.kalbfuss@web.de wrote:
> Hallo guys,
>=20
> my idea is about the possibility to read in file at compile time using
> static_read.
> The file content ist returned as a string literal, which can be processed
> afterwards.
> Important is, that the the returned string literal is constexpr. You can
> use it as
> template parameter or inside constexpr functions.
> What is it good for?
>=20
> Think of an BNF or EBNF grammer described in a external file. This file i=
s
> transformed into a string literal. The string literal could be transforme=
d
> into a parser
> at compile time, using a contexpr function.
>=20
> This is not limited to BNF or EBNF. It works for all kind of domain
> specific languages.
> Another usage are data files. ll kind of xml files could be transformed
> to C++ Data structures, for example.

What's wrong with using a code generator tool that reads the file and produ=
ces=20
a header with the constexpr string?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/12463358.l9y6zcXXmN%40tjmaciei-mobl1.

.


Author: Peter Sommerlad <peter.sommerlad@hsr.ch>
Date: Sat, 20 May 2017 13:39:28 -0600
Raw View
"\
#include <file>\
"
?
send from a mobile device.
Prof. Peter Sommerlad
peter.Sommerlad@hsr.ch
+41-79-432 23 32

> On 20 May 2017, at 13:30, Thiago Macieira <thiago@macieira.org> wrote:
>=20
>> On s=C3=A1bado, 20 de maio de 2017 11:32:28 PDT ma.kalbfuss@web.de wrote=
:
>> Hallo guys,
>>=20
>> my idea is about the possibility to read in file at compile time using
>> static_read.
>> The file content ist returned as a string literal, which can be processe=
d
>> afterwards.
>> Important is, that the the returned string literal is constexpr. You can
>> use it as
>> template parameter or inside constexpr functions.
>> What is it good for?
>>=20
>> Think of an BNF or EBNF grammer described in a external file. This file =
is
>> transformed into a string literal. The string literal could be transform=
ed
>> into a parser
>> at compile time, using a contexpr function.
>>=20
>> This is not limited to BNF or EBNF. It works for all kind of domain
>> specific languages.
>> Another usage are data files. ll kind of xml files could be transformed
>> to C++ Data structures, for example.
>=20
> What's wrong with using a code generator tool that reads the file and pro=
duces=20
> a header with the constexpr string?
>=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Software Architect - Intel Open Source Technology Center
>=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=
 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/12463358.l9y6zcXXmN%40tjmaciei-mobl1.

--=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/C5A6B1F0-83B0-44C9-A685-91CB56FD7630%40hsr.ch.

.


Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sun, 21 May 2017 09:56:51 -0700 (PDT)
Raw View
------=_Part_2249_609972394.1495385812019
Content-Type: multipart/alternative;
 boundary="----=_Part_2250_1906866558.1495385812019"

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

On Saturday, May 20, 2017 at 11:32:28 AM UTC-7, ma.ka...@web.de wrote:
>
> Hallo guys,
>
> my idea is about the possibility to read in file at compile time using=20
> static_read.
> The file content ist returned as a string literal, which can be processed=
=20
> afterwards.
> Important is, that the the returned string literal is constexpr. You can=
=20
> use it as
> template parameter or inside constexpr functions.
>

Coincidentally, this topic just came up in conversation yesterday after a=
=20
couple of years of not thinking about it. Strange synchronicity. :)
Here's a proposal on the subject from May 2016:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf

To Peter's question: no, you can't just put an #include directive inside a=
=20
string, because "inside a string" there are by definition only characters.
"\
#include <foo>\
"
is equivalent (after backslash-replacement) to
"#include <foo>"
which doesn't have anything to do with a file named "foo" as far as the=20
compiler is concerned.

So the above-linked proposal =E2=80=94 which was extensively discussed on t=
his very=20
mailing list; maybe you can dig up the thread(s) =E2=80=94 proposed that we=
=20
introduce a completely new kind of string literal: F"foo" means "open the=
=20
file named foo and dump its contents into this string."

I don't know whether the proposal was ever discussed in Committee.=20
Personally I think it has two major hurdles to overcome:
- it's a preprocessor feature request, and changing the preprocessor sucks=
=20
(because C compatibility; because modules)
- it's proposing a completely new *dimension* of stringness, on top of the=
=20
two dimensions we already have

Consider: if F"foo" is the contents of file foo, what is u8F"foo"? what is=
=20
LF"foo"? In short, what is the interaction between the C++ notions of=20
"character set" and "encoding" with the filesystem concept of "the text=20
stored in this file"?  =E2=80=94 Please note that this horse was absolutely=
 beaten=20
to death in the old thread, so I do recommend that you go dig it up and=20
read it. But, for people who aren't the OP and yet might still want to=20
debate the topic, please do read the proposal P0373r0=20
<http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf>, since it=
=20
has a lot to say on the subject and can get you up to speed on the issues=
=20
relatively quickly.

HTH,
=E2=80=93Arthur

--=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/1315afc0-8ab9-40a1-aed2-7e2e806405a0%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, May 20, 2017 at 11:32:28 AM UTC-7, ma.ka...@w=
eb.de wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">H=
allo guys,<br><br>my idea is about the possibility to read in file at compi=
le time using static_read.<br>The file content ist returned as a string lit=
eral, which can be processed afterwards.<br>Important is, that the the retu=
rned string literal is constexpr. You can use it as<br>template parameter o=
r inside constexpr functions.<br></div></blockquote><div><br></div><div>Coi=
ncidentally, this topic just came up in conversation yesterday after a coup=
le of years of not thinking about it. Strange synchronicity. :)</div><div>H=
ere&#39;s a proposal on the subject from May 2016:</div><div><a href=3D"htt=
p://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf">http://open-s=
td.org/JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf<br></a></div><div><br></=
div><div>To Peter&#39;s question: no, you can&#39;t just put an #include di=
rective inside a string, because &quot;inside a string&quot; there are by d=
efinition only characters.</div><div><font face=3D"courier new, monospace">=
&quot;\</font></div><div><font face=3D"courier new, monospace">#include &lt=
;foo&gt;\</font></div><div><font face=3D"courier new, monospace">&quot;</fo=
nt></div><div>is equivalent (after backslash-replacement) to</div><div><fon=
t face=3D"courier new, monospace">&quot;#include &lt;foo&gt;&quot;</font></=
div><div>which doesn&#39;t have anything to do with a file named &quot;foo&=
quot; as far as the compiler is concerned.</div><div><br></div><div>So the =
above-linked proposal =E2=80=94 which was extensively discussed on this ver=
y mailing list; maybe you can dig up the thread(s) =E2=80=94 proposed that =
we introduce a completely new kind of string literal: <font face=3D"courier=
 new, monospace">F&quot;foo&quot;</font> means &quot;open the file named fo=
o and dump its contents into this string.&quot;</div><div><br></div><div>I =
don&#39;t know whether the proposal was ever discussed in Committee. Person=
ally I think it has two major hurdles to overcome:</div><div>- it&#39;s a p=
reprocessor feature request, and changing the preprocessor sucks (because C=
 compatibility; because modules)</div><div>- it&#39;s proposing a completel=
y new <i>dimension</i> of stringness, on top of the two dimensions we alrea=
dy have</div><div><br></div><div>Consider: if F&quot;foo&quot; is the conte=
nts of file foo, what is u8F&quot;foo&quot;? what is LF&quot;foo&quot;? In =
short, what is the interaction between the C++ notions of &quot;character s=
et&quot; and &quot;encoding&quot; with the filesystem concept of &quot;the =
text stored in this file&quot;? =C2=A0=E2=80=94 Please note that this horse=
 was absolutely beaten to death in the old thread, so I do recommend that y=
ou go dig it up and read it. But, for people who aren&#39;t the OP and yet =
might still want to debate the topic, please do <a href=3D"http://open-std.=
org/JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf">read the proposal P0373r0<=
/a>, since it has a lot to say on the subject and can get you up to speed o=
n the issues relatively quickly.</div><div><br></div><div>HTH,</div><div>=
=E2=80=93Arthur</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/1315afc0-8ab9-40a1-aed2-7e2e806405a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1315afc0-8ab9-40a1-aed2-7e2e806405a0=
%40isocpp.org</a>.<br />

------=_Part_2250_1906866558.1495385812019--

------=_Part_2249_609972394.1495385812019--

.


Author: ma.kalbfuss@web.de
Date: Sun, 21 May 2017 23:37:38 -0700 (PDT)
Raw View
------=_Part_2525_1879484948.1495435058718
Content-Type: multipart/alternative;
 boundary="----=_Part_2526_784455300.1495435058719"

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

Really interesting. A nice idea to introduce a new kind of string literal.=
=20
Thanks for the hint.

Am Sonntag, 21. Mai 2017 18:56:52 UTC+2 schrieb Arthur O'Dwyer:
>
> On Saturday, May 20, 2017 at 11:32:28 AM UTC-7, ma.ka...@web.de wrote:
>>
>> Hallo guys,
>>
>> my idea is about the possibility to read in file at compile time using=
=20
>> static_read.
>> The file content ist returned as a string literal, which can be processe=
d=20
>> afterwards.
>> Important is, that the the returned string literal is constexpr. You can=
=20
>> use it as
>> template parameter or inside constexpr functions.
>>
>
> Coincidentally, this topic just came up in conversation yesterday after a=
=20
> couple of years of not thinking about it. Strange synchronicity. :)
> Here's a proposal on the subject from May 2016:
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf
>
> To Peter's question: no, you can't just put an #include directive inside =
a=20
> string, because "inside a string" there are by definition only characters=
..
> "\
> #include <foo>\
> "
> is equivalent (after backslash-replacement) to
> "#include <foo>"
> which doesn't have anything to do with a file named "foo" as far as the=
=20
> compiler is concerned.
>
> So the above-linked proposal =E2=80=94 which was extensively discussed on=
 this=20
> very mailing list; maybe you can dig up the thread(s) =E2=80=94 proposed =
that we=20
> introduce a completely new kind of string literal: F"foo" means "open the=
=20
> file named foo and dump its contents into this string."
>
> I don't know whether the proposal was ever discussed in Committee.=20
> Personally I think it has two major hurdles to overcome:
> - it's a preprocessor feature request, and changing the preprocessor suck=
s=20
> (because C compatibility; because modules)
> - it's proposing a completely new *dimension* of stringness, on top of=20
> the two dimensions we already have
>
> Consider: if F"foo" is the contents of file foo, what is u8F"foo"? what i=
s=20
> LF"foo"? In short, what is the interaction between the C++ notions of=20
> "character set" and "encoding" with the filesystem concept of "the text=
=20
> stored in this file"?  =E2=80=94 Please note that this horse was absolute=
ly beaten=20
> to death in the old thread, so I do recommend that you go dig it up and=
=20
> read it. But, for people who aren't the OP and yet might still want to=20
> debate the topic, please do read the proposal P0373r0=20
> <http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf>, since=
=20
> it has a lot to say on the subject and can get you up to speed on the=20
> issues relatively quickly.
>
> HTH,
> =E2=80=93Arthur
>

--=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/12df232a-b3ce-4f5b-86cf-9a3bfba4853c%40isocpp.or=
g.

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

<div dir=3D"ltr">Really interesting. A nice idea to introduce a new kind of=
 string literal. Thanks for the hint.<br><br>Am Sonntag, 21. Mai 2017 18:56=
:52 UTC+2 schrieb Arthur O&#39;Dwyer:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr">On Saturday, May 20, 2017 at 11:32:28 AM UTC-7, <a>=
ma.ka...@web.de</a> wrote:<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">Hallo guys,<br><br>my idea is about the possibility to read in fil=
e at compile time using static_read.<br>The file content ist returned as a =
string literal, which can be processed afterwards.<br>Important is, that th=
e the returned string literal is constexpr. You can use it as<br>template p=
arameter or inside constexpr functions.<br></div></blockquote><div><br></di=
v><div>Coincidentally, this topic just came up in conversation yesterday af=
ter a couple of years of not thinking about it. Strange synchronicity. :)</=
div><div>Here&#39;s a proposal on the subject from May 2016:</div><div><a h=
ref=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2=
Fpapers%2F2016%2Fp0373r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE6ahfG=
o-Uh-yxbrUauwzec-_EtIQ&#39;;return true;" onclick=3D"this.href=3D&#39;http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2F=
docs%2Fpapers%2F2016%2Fp0373r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
E6ahfGo-Uh-yxbrUauwzec-_EtIQ&#39;;return true;">http://open-std.org/JTC1/SC=
22/<wbr>WG21/docs/papers/2016/p0373r0.<wbr>pdf<br></a></div><div><br></div>=
<div>To Peter&#39;s question: no, you can&#39;t just put an #include direct=
ive inside a string, because &quot;inside a string&quot; there are by defin=
ition only characters.</div><div><font face=3D"courier new, monospace">&quo=
t;\</font></div><div><font face=3D"courier new, monospace">#include &lt;foo=
&gt;\</font></div><div><font face=3D"courier new, monospace">&quot;</font><=
/div><div>is equivalent (after backslash-replacement) to</div><div><font fa=
ce=3D"courier new, monospace">&quot;#include &lt;foo&gt;&quot;</font></div>=
<div>which doesn&#39;t have anything to do with a file named &quot;foo&quot=
; as far as the compiler is concerned.</div><div><br></div><div>So the abov=
e-linked proposal =E2=80=94 which was extensively discussed on this very ma=
iling list; maybe you can dig up the thread(s) =E2=80=94 proposed that we i=
ntroduce a completely new kind of string literal: <font face=3D"courier new=
, monospace">F&quot;foo&quot;</font> means &quot;open the file named foo an=
d dump its contents into this string.&quot;</div><div><br></div><div>I don&=
#39;t know whether the proposal was ever discussed in Committee. Personally=
 I think it has two major hurdles to overcome:</div><div>- it&#39;s a prepr=
ocessor feature request, and changing the preprocessor sucks (because C com=
patibility; because modules)</div><div>- it&#39;s proposing a completely ne=
w <i>dimension</i> of stringness, on top of the two dimensions we already h=
ave</div><div><br></div><div>Consider: if F&quot;foo&quot; is the contents =
of file foo, what is u8F&quot;foo&quot;? what is LF&quot;foo&quot;? In shor=
t, what is the interaction between the C++ notions of &quot;character set&q=
uot; and &quot;encoding&quot; with the filesystem concept of &quot;the text=
 stored in this file&quot;? =C2=A0=E2=80=94 Please note that this horse was=
 absolutely beaten to death in the old thread, so I do recommend that you g=
o dig it up and read it. But, for people who aren&#39;t the OP and yet migh=
t still want to debate the topic, please do <a href=3D"http://open-std.org/=
JTC1/SC22/WG21/docs/papers/2016/p0373r0.pdf" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A=
%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2016%2Fp0373r0.pd=
f\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE6ahfGo-Uh-yxbrUauwzec-_EtIQ&#39;=
;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2016%2Fp037=
3r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE6ahfGo-Uh-yxbrUauwzec-_EtI=
Q&#39;;return true;">read the proposal P0373r0</a>, since it has a lot to s=
ay on the subject and can get you up to speed on the issues relatively quic=
kly.</div><div><br></div><div>HTH,</div><div>=E2=80=93Arthur</div></div></b=
lockquote></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/12df232a-b3ce-4f5b-86cf-9a3bfba4853c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/12df232a-b3ce-4f5b-86cf-9a3bfba4853c=
%40isocpp.org</a>.<br />

------=_Part_2526_784455300.1495435058719--

------=_Part_2525_1879484948.1495435058718--

.


Author: olaf@join.cc
Date: Wed, 24 May 2017 01:58:43 -0700 (PDT)
Raw View
------=_Part_4121_632664711.1495616323477
Content-Type: multipart/alternative;
 boundary="----=_Part_4122_1296658876.1495616323477"

------=_Part_4122_1296658876.1495616323477
Content-Type: text/plain; charset="UTF-8"



Op zaterdag 20 mei 2017 20:32:28 UTC+2 schreef ma.ka...@web.de:
>
> Hallo guys,
>
> my idea is about the possibility to read in file at compile time using
> static_read.
> The file content ist returned as a string literal, which can be processed
> afterwards.
> Important is, that the the returned string literal is constexpr. You can
> use it as
> template parameter or inside constexpr functions.
> What is it good for?
>
>
https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!msg/std-proposals/WciaY0IJ4ak/7gsGpqRiRaUJ;context-place=topic/std-proposals/b6ncBojU8wI

https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/std-proposals/b6ncBojU8wI%5B26-50%5D



--
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/c0c10596-e406-4963-98c2-a96e4d81591e%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Op zaterdag 20 mei 2017 20:32:28 UTC+2 schreef ma.=
ka...@web.de:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Hallo guys,<br><br>my idea is about the possibility to read in file at comp=
ile time using static_read.<br>The file content ist returned as a string li=
teral, which can be processed afterwards.<br>Important is, that the the ret=
urned string literal is constexpr. You can use it as<br>template parameter =
or inside constexpr functions.<br>What is it good for?<br><br></div></block=
quote><div><br></div><div>https://groups.google.com/a/isocpp.org/forum/?fro=
mgroups=3D#!msg/std-proposals/WciaY0IJ4ak/7gsGpqRiRaUJ;context-place=3Dtopi=
c/std-proposals/b6ncBojU8wI<br></div><div><br></div><div>https://groups.goo=
gle.com/a/isocpp.org/forum/?fromgroups=3D#!topic/std-proposals/b6ncBojU8wI%=
5B26-50%5D</div><div><br></div><div>=C2=A0</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/c0c10596-e406-4963-98c2-a96e4d81591e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0c10596-e406-4963-98c2-a96e4d81591e=
%40isocpp.org</a>.<br />

------=_Part_4122_1296658876.1495616323477--

------=_Part_4121_632664711.1495616323477--

.