------=_Part_465_46586802.1424025533359
Content-Type: multipart/alternative;
 boundary="----=_Part_466_1300333706.1424025533359"

------=_Part_466_1300333706.1424025533359
Content-Type: text/plain; charset=UTF-8

Hi,

Apologies if this has been discussed before. This is something I've wanted
in C++ for ages and it seems trivial, so here goes my (first ever) informal
proposal. Let me know what you think!

# Overview

I propose a method for including an external file in a .cpp file, but
instead of copy/pasting code as #include does, it will create a char array
containing the file contents.

# Motivation

People have wanted something like this for decades for including assets in
a binary. Some uses include:

* Images
* OpenGL shaders
* HTML templates

The lack of a standard built in, cross platform way to include these has
lead to hacks like the XPM image format, and recently this method using GCC
assembly:

https://github.com/graphitemaster/incbin

Uses of this include both binary files (which might contain null
characters) and text files, so the syntax should support both.

# Syntax

Obviously there are a million different possible syntaxes. I propose this:

    #load "shader.vert" main_shader main_shader_len

Which works in exactly the same way as #include (i.e. you can use "" quotes
and <> brackets with the same search path), but the contents of the file
are loaded as follows:

    const char[] main_shader = <the contents of the file>;
    const int main_shader_len = <the length of the file>;

The length variable is optional.

# Obvious objections

* No way to specify if it is static or not.
* No way to specify alignment (it should have a sane default, e.g. machine
word size).
* Should it be char or uint8_t? I'm not sure; I'm not really a C++ guru and
I mostly ignore the esoteric difference (char is technically only 7 bit,
etc.)
* Syntax bikeshedding.

It's not perfect and all-encompassing, but it is very simple and way better
than anything we have now.

Cheers,

Tim

--

---
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_466_1300333706.1424025533359
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Apologies if this has been discusse=
d before. This is something I've wanted in C++ for ages and it seems trivia=
l, so here goes my (first ever) informal proposal. Let me know what you thi=
nk!</div><div><br></div><div># Overview<br></div><div><br></div><div>I prop=
ose a method for including an external file in a .cpp file, but instead of =
copy/pasting code as #include does, it will create a char array containing =
the file contents.</div><div><br></div><div># Motivation</div><div><br></di=
v><div>People have wanted something like this for decades for including ass=
ets in a binary. Some uses include:</div><div><br></div><div>* Images</div>=
<div>* OpenGL shaders</div><div>* HTML templates</div><div><br></div><div>T=
he lack of a standard built in, cross platform way to include these has lea=
d to hacks like the XPM image format, and recently this method using GCC as=
sembly:&nbsp;</div><div><br></div><div>https://github.com/graphitemaster/in=
cbin<br></div><div><br></div><div>Uses of this include both binary files (w=
hich might contain null characters) and text files, so the syntax should su=
pport both.</div><div><br></div><div># Syntax</div><div><br></div><div>Obvi=
ously there are a million different possible syntaxes. I propose this:</div=
><div><br></div><div>&nbsp; &nbsp; #load "shader.vert" main_shader main_sha=
der_len</div><div><br></div><div>Which works in exactly the same way as #in=
clude (i.e. you can use "" quotes and &lt;&gt; brackets with the same searc=
h path), but the contents of the file are loaded as follows:</div><div><br>=
</div><div>&nbsp; &nbsp; const char[] main_shader =3D &lt;the contents of t=
he file&gt;;</div><div>&nbsp; &nbsp; const int main_shader_len =3D &lt;the =
length of the file&gt;;</div><div><br></div><div>The length variable is opt=
ional.</div><div><br></div><div># Obvious objections</div><div><br></div><d=
iv>* No way to specify if it is static or not.</div><div>* No way to specif=
y alignment (it should have a sane default, e.g. machine word size).</div><=
div>* Should it be char or uint8_t? I'm not sure; I'm not really a C++ guru=
 and I mostly ignore the esoteric difference (char is technically only 7 bi=
t, etc.)<br></div><div>* Syntax bikeshedding.</div><div><br></div><div>It's=
 not perfect and all-encompassing, but it is very simple and way better tha=
n anything we have now.</div><div><br></div><div>Cheers,</div><div><br></di=
v><div>Tim</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_466_1300333706.1424025533359--
------=_Part_465_46586802.1424025533359--

.

------=_Part_565_2086671389.1424026693349
Content-Type: multipart/alternative;
 boundary="----=_Part_566_194751928.1424026693349"

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

Sorry to disappoint you but people those days doesn't bother with=20
meta-programming and thus don't care for it - you're out of luck. People=20
now days will rather go copy paste the whole file manually or by using some=
=20
external scripting language. Otherwise there is a lot more general solution=
=20
for such problems that I had written on ages ago and which involves=20
'constexpr' function and classes for manipulating internal data structures=
=20
(like creating member names by using common string patterns, editing=20
existing classes, namespaces, creating a lot faster code in which is=20
determined which will be evaluated on compilation and which should be=20
executed and so).

But don't worry - you may not be so unlucky as this proposal seems simple=
=20
enough to be considered.

=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=
=B0=D1=80=D0=B8 2015 =D0=B3., 20:38:53 UTC+2, tdh...@gmail.com =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>
> Hi,
>
> Apologies if this has been discussed before. This is something I've wante=
d=20
> in C++ for ages and it seems trivial, so here goes my (first ever) inform=
al=20
> proposal. Let me know what you think!
>
> # Overview
>
> I propose a method for including an external file in a .cpp file, but=20
> instead of copy/pasting code as #include does, it will create a char arra=
y=20
> containing the file contents.
>
> # Motivation
>
> People have wanted something like this for decades for including assets i=
n=20
> a binary. Some uses include:
>
> * Images
> * OpenGL shaders
> * HTML templates
>
> The lack of a standard built in, cross platform way to include these has=
=20
> lead to hacks like the XPM image format, and recently this method using G=
CC=20
> assembly:=20
>
> https://github.com/graphitemaster/incbin
>
> Uses of this include both binary files (which might contain null=20
> characters) and text files, so the syntax should support both.
>
> # Syntax
>
> Obviously there are a million different possible syntaxes. I propose this=
:
>
>     #load "shader.vert" main_shader main_shader_len
>
> Which works in exactly the same way as #include (i.e. you can use ""=20
> quotes and <> brackets with the same search path), but the contents of th=
e=20
> file are loaded as follows:
>
>     const char[] main_shader =3D <the contents of the file>;
>     const int main_shader_len =3D <the length of the file>;
>
> The length variable is optional.
>
> # Obvious objections
>
> * No way to specify if it is static or not.
> * No way to specify alignment (it should have a sane default, e.g. machin=
e=20
> word size).
> * Should it be char or uint8_t? I'm not sure; I'm not really a C++ guru=
=20
> and I mostly ignore the esoteric difference (char is technically only 7=
=20
> bit, etc.)
> * Syntax bikeshedding.
>
> It's not perfect and all-encompassing, but it is very simple and way=20
> better than anything we have now.
>
> Cheers,
>
> Tim
>

--=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_566_194751928.1424026693349
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry to disappoint you but people those days doesn't both=
er with meta-programming and thus don't care for it - you're out of luck. P=
eople now days will rather go copy paste the whole file manually or by usin=
g some external scripting language. Otherwise there is a lot more general s=
olution for such problems that I had written on ages ago and which involves=
 'constexpr' function and classes for manipulating internal data structures=
 (like creating member names by using common string patterns, editing exist=
ing classes, namespaces, creating a lot faster code in which is determined =
which will be evaluated on compilation and which should be executed and so)=
..<br><br>But don't worry - you may not be so unlucky as this proposal seems=
 simple enough to be considered.<br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=
=8F, 15 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 20:3=
8:53 UTC+2, tdh...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi,<div><br></div><div=
>Apologies if this has been discussed before. This is something I've wanted=
 in C++ for ages and it seems trivial, so here goes my (first ever) informa=
l proposal. Let me know what you think!</div><div><br></div><div># Overview=
<br></div><div><br></div><div>I propose a method for including an external =
file in a .cpp file, but instead of copy/pasting code as #include does, it =
will create a char array containing the file contents.</div><div><br></div>=
<div># Motivation</div><div><br></div><div>People have wanted something lik=
e this for decades for including assets in a binary. Some uses include:</di=
v><div><br></div><div>* Images</div><div>* OpenGL shaders</div><div>* HTML =
templates</div><div><br></div><div>The lack of a standard built in, cross p=
latform way to include these has lead to hacks like the XPM image format, a=
nd recently this method using GCC assembly:&nbsp;</div><div><br></div><div>=
<a href=3D"https://github.com/graphitemaster/incbin" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Fgithub.com%2Fgraphitemaster%2Fincbin\46sa\75D\46sntz\0751\46usg=
\75AFQjCNFF5wq_BomCjXFyZaFvaYHFxns-pg';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgraphitemaste=
r%2Fincbin\46sa\75D\46sntz\0751\46usg\75AFQjCNFF5wq_BomCjXFyZaFvaYHFxns-pg'=
;return true;">https://github.com/<wbr>graphitemaster/incbin</a><br></div><=
div><br></div><div>Uses of this include both binary files (which might cont=
ain null characters) and text files, so the syntax should support both.</di=
v><div><br></div><div># Syntax</div><div><br></div><div>Obviously there are=
 a million different possible syntaxes. I propose this:</div><div><br></div=
><div>&nbsp; &nbsp; #load "shader.vert" main_shader main_shader_len</div><d=
iv><br></div><div>Which works in exactly the same way as #include (i.e. you=
 can use "" quotes and &lt;&gt; brackets with the same search path), but th=
e contents of the file are loaded as follows:</div><div><br></div><div>&nbs=
p; &nbsp; const char[] main_shader =3D &lt;the contents of the file&gt;;</d=
iv><div>&nbsp; &nbsp; const int main_shader_len =3D &lt;the length of the f=
ile&gt;;</div><div><br></div><div>The length variable is optional.</div><di=
v><br></div><div># Obvious objections</div><div><br></div><div>* No way to =
specify if it is static or not.</div><div>* No way to specify alignment (it=
 should have a sane default, e.g. machine word size).</div><div>* Should it=
 be char or uint8_t? I'm not sure; I'm not really a C++ guru and I mostly i=
gnore the esoteric difference (char is technically only 7 bit, etc.)<br></d=
iv><div>* Syntax bikeshedding.</div><div><br></div><div>It's not perfect an=
d all-encompassing, but it is very simple and way better than anything we h=
ave now.</div><div><br></div><div>Cheers,</div><div><br></div><div>Tim</div=
></div></blockquote></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_566_194751928.1424026693349--
------=_Part_565_2086671389.1424026693349--

.

What about using a std::array?

On 2/15/15, sasho648 <sasho648@mail.bg> wrote:
> Sorry to disappoint you but people those days doesn't bother with
> meta-programming and thus don't care for it - you're out of luck. People
> now days will rather go copy paste the whole file manually or by using so=
me
>
> external scripting language. Otherwise there is a lot more general soluti=
on
>
> for such problems that I had written on ages ago and which involves
> 'constexpr' function and classes for manipulating internal data structure=
s
> (like creating member names by using common string patterns, editing
> existing classes, namespaces, creating a lot faster code in which is
> determined which will be evaluated on compilation and which should be
> executed and so).
>
> But don't worry - you may not be so unlucky as this proposal seems simple
> enough to be considered.
>
> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D1=84=D0=B5=D0=B2=D1=80=D1=83=
=D0=B0=D1=80=D0=B8 2015 =D0=B3., 20:38:53 UTC+2, tdh...@gmail.com =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>
>> Hi,
>>
>> Apologies if this has been discussed before. This is something I've want=
ed
>>
>> in C++ for ages and it seems trivial, so here goes my (first ever)
>> informal
>> proposal. Let me know what you think!
>>
>> # Overview
>>
>> I propose a method for including an external file in a .cpp file, but
>> instead of copy/pasting code as #include does, it will create a char arr=
ay
>>
>> containing the file contents.
>>
>> # Motivation
>>
>> People have wanted something like this for decades for including assets =
in
>>
>> a binary. Some uses include:
>>
>> * Images
>> * OpenGL shaders
>> * HTML templates
>>
>> The lack of a standard built in, cross platform way to include these has
>> lead to hacks like the XPM image format, and recently this method using
>> GCC
>> assembly:
>>
>> https://github.com/graphitemaster/incbin
>>
>> Uses of this include both binary files (which might contain null
>> characters) and text files, so the syntax should support both.
>>
>> # Syntax
>>
>> Obviously there are a million different possible syntaxes. I propose
>> this:
>>
>>     #load "shader.vert" main_shader main_shader_len
>>
>> Which works in exactly the same way as #include (i.e. you can use ""
>> quotes and <> brackets with the same search path), but the contents of t=
he
>>
>> file are loaded as follows:
>>
>>     const char[] main_shader =3D <the contents of the file>;
>>     const int main_shader_len =3D <the length of the file>;
>>
>> The length variable is optional.
>>
>> # Obvious objections
>>
>> * No way to specify if it is static or not.
>> * No way to specify alignment (it should have a sane default, e.g. machi=
ne
>>
>> word size).
>> * Should it be char or uint8_t? I'm not sure; I'm not really a C++ guru
>> and I mostly ignore the esoteric difference (char is technically only 7
>> bit, etc.)
>> * Syntax bikeshedding.
>>
>> It's not perfect and all-encompassing, but it is very simple and way
>> better than anything we have now.
>>
>> Cheers,
>>
>> Tim
>>
>
> --
>
> ---
> 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/.

.

------=_Part_338_735832544.1424041085270
Content-Type: multipart/alternative;
 boundary="----=_Part_339_1926727582.1424041085270"

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

What about using more than one sentence to express your thoughts?

=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=
=B0=D1=80=D0=B8 2015 =D0=B3., 20:38:53 UTC+2, tdh...@gmail.com =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>
> Hi,
>
> Apologies if this has been discussed before. This is something I've wante=
d=20
> in C++ for ages and it seems trivial, so here goes my (first ever) inform=
al=20
> proposal. Let me know what you think!
>
> # Overview
>
> I propose a method for including an external file in a .cpp file, but=20
> instead of copy/pasting code as #include does, it will create a char arra=
y=20
> containing the file contents.
>
> # Motivation
>
> People have wanted something like this for decades for including assets i=
n=20
> a binary. Some uses include:
>
> * Images
> * OpenGL shaders
> * HTML templates
>
> The lack of a standard built in, cross platform way to include these has=
=20
> lead to hacks like the XPM image format, and recently this method using G=
CC=20
> assembly:=20
>
> https://github.com/graphitemaster/incbin
>
> Uses of this include both binary files (which might contain null=20
> characters) and text files, so the syntax should support both.
>
> # Syntax
>
> Obviously there are a million different possible syntaxes. I propose this=
:
>
>     #load "shader.vert" main_shader main_shader_len
>
> Which works in exactly the same way as #include (i.e. you can use ""=20
> quotes and <> brackets with the same search path), but the contents of th=
e=20
> file are loaded as follows:
>
>     const char[] main_shader =3D <the contents of the file>;
>     const int main_shader_len =3D <the length of the file>;
>
> The length variable is optional.
>
> # Obvious objections
>
> * No way to specify if it is static or not.
> * No way to specify alignment (it should have a sane default, e.g. machin=
e=20
> word size).
> * Should it be char or uint8_t? I'm not sure; I'm not really a C++ guru=
=20
> and I mostly ignore the esoteric difference (char is technically only 7=
=20
> bit, etc.)
> * Syntax bikeshedding.
>
> It's not perfect and all-encompassing, but it is very simple and way=20
> better than anything we have now.
>
> Cheers,
>
> Tim
>

--=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_339_1926727582.1424041085270
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What about using more than one sentence to express your th=
oughts?<br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D1=84=D0=B5=D0=B2=
=D1=80=D1=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 20:38:53 UTC+2, tdh...@gmail.c=
om =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<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">Hi,<div><br></div><div>Apologies if this has bee=
n discussed before. This is something I've wanted in C++ for ages and it se=
ems trivial, so here goes my (first ever) informal proposal. Let me know wh=
at you think!</div><div><br></div><div># Overview<br></div><div><br></div><=
div>I propose a method for including an external file in a .cpp file, but i=
nstead of copy/pasting code as #include does, it will create a char array c=
ontaining the file contents.</div><div><br></div><div># Motivation</div><di=
v><br></div><div>People have wanted something like this for decades for inc=
luding assets in a binary. Some uses include:</div><div><br></div><div>* Im=
ages</div><div>* OpenGL shaders</div><div>* HTML templates</div><div><br></=
div><div>The lack of a standard built in, cross platform way to include the=
se has lead to hacks like the XPM image format, and recently this method us=
ing GCC assembly:&nbsp;</div><div><br></div><div><a href=3D"https://github.=
com/graphitemaster/incbin" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2F=
graphitemaster%2Fincbin\46sa\75D\46sntz\0751\46usg\75AFQjCNFF5wq_BomCjXFyZa=
FvaYHFxns-pg';return true;" onclick=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fgithub.com%2Fgraphitemaster%2Fincbin\46sa\75D\46sntz\=
0751\46usg\75AFQjCNFF5wq_BomCjXFyZaFvaYHFxns-pg';return true;">https://gith=
ub.com/<wbr>graphitemaster/incbin</a><br></div><div><br></div><div>Uses of =
this include both binary files (which might contain null characters) and te=
xt files, so the syntax should support both.</div><div><br></div><div># Syn=
tax</div><div><br></div><div>Obviously there are a million different possib=
le syntaxes. I propose this:</div><div><br></div><div>&nbsp; &nbsp; #load "=
shader.vert" main_shader main_shader_len</div><div><br></div><div>Which wor=
ks in exactly the same way as #include (i.e. you can use "" quotes and &lt;=
&gt; brackets with the same search path), but the contents of the file are =
loaded as follows:</div><div><br></div><div>&nbsp; &nbsp; const char[] main=
_shader =3D &lt;the contents of the file&gt;;</div><div>&nbsp; &nbsp; const=
 int main_shader_len =3D &lt;the length of the file&gt;;</div><div><br></di=
v><div>The length variable is optional.</div><div><br></div><div># Obvious =
objections</div><div><br></div><div>* No way to specify if it is static or =
not.</div><div>* No way to specify alignment (it should have a sane default=
, e.g. machine word size).</div><div>* Should it be char or uint8_t? I'm no=
t sure; I'm not really a C++ guru and I mostly ignore the esoteric differen=
ce (char is technically only 7 bit, etc.)<br></div><div>* Syntax bikesheddi=
ng.</div><div><br></div><div>It's not perfect and all-encompassing, but it =
is very simple and way better than anything we have now.</div><div><br></di=
v><div>Cheers,</div><div><br></div><div>Tim</div></div></blockquote></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_339_1926727582.1424041085270--
------=_Part_338_735832544.1424041085270--

.

------=_Part_564_1963471541.1424041116349
Content-Type: multipart/alternative;
 boundary="----=_Part_565_1832469785.1424041116349"

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

What about using more than one sentence to express your thoughts

=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=
=B0=D1=80=D0=B8 2015 =D0=B3., 23:45:12 UTC+2, Douglas Boffey =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>
> What about using a std::array?=20
>
> On 2/15/15, sasho648 <sash...@mail.bg <javascript:>> wrote:=20
> > Sorry to disappoint you but people those days doesn't bother with=20
> > meta-programming and thus don't care for it - you're out of luck. Peopl=
e=20
> > now days will rather go copy paste the whole file manually or by using=
=20
> some=20
> >=20
> > external scripting language. Otherwise there is a lot more general=20
> solution=20
> >=20
> > for such problems that I had written on ages ago and which involves=20
> > 'constexpr' function and classes for manipulating internal data=20
> structures=20
> > (like creating member names by using common string patterns, editing=20
> > existing classes, namespaces, creating a lot faster code in which is=20
> > determined which will be evaluated on compilation and which should be=
=20
> > executed and so).=20
> >=20
> > But don't worry - you may not be so unlucky as this proposal seems=20
> simple=20
> > enough to be considered.=20
> >=20
> > =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D1=84=D0=B5=D0=B2=D1=80=D1=83=
=D0=B0=D1=80=D0=B8 2015 =D0=B3., 20:38:53 UTC+2, tdh...@gmail.com =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:=20
> >>=20
> >> Hi,=20
> >>=20
> >> Apologies if this has been discussed before. This is something I've=20
> wanted=20
> >>=20
> >> in C++ for ages and it seems trivial, so here goes my (first ever)=20
> >> informal=20
> >> proposal. Let me know what you think!=20
> >>=20
> >> # Overview=20
> >>=20
> >> I propose a method for including an external file in a .cpp file, but=
=20
> >> instead of copy/pasting code as #include does, it will create a char=
=20
> array=20
> >>=20
> >> containing the file contents.=20
> >>=20
> >> # Motivation=20
> >>=20
> >> People have wanted something like this for decades for including asset=
s=20
> in=20
> >>=20
> >> a binary. Some uses include:=20
> >>=20
> >> * Images=20
> >> * OpenGL shaders=20
> >> * HTML templates=20
> >>=20
> >> The lack of a standard built in, cross platform way to include these=
=20
> has=20
> >> lead to hacks like the XPM image format, and recently this method usin=
g=20
> >> GCC=20
> >> assembly:=20
> >>=20
> >> https://github.com/graphitemaster/incbin=20
> >>=20
> >> Uses of this include both binary files (which might contain null=20
> >> characters) and text files, so the syntax should support both.=20
> >>=20
> >> # Syntax=20
> >>=20
> >> Obviously there are a million different possible syntaxes. I propose=
=20
> >> this:=20
> >>=20
> >>     #load "shader.vert" main_shader main_shader_len=20
> >>=20
> >> Which works in exactly the same way as #include (i.e. you can use ""=
=20
> >> quotes and <> brackets with the same search path), but the contents of=
=20
> the=20
> >>=20
> >> file are loaded as follows:=20
> >>=20
> >>     const char[] main_shader =3D <the contents of the file>;=20
> >>     const int main_shader_len =3D <the length of the file>;=20
> >>=20
> >> The length variable is optional.=20
> >>=20
> >> # Obvious objections=20
> >>=20
> >> * No way to specify if it is static or not.=20
> >> * No way to specify alignment (it should have a sane default, e.g.=20
> machine=20
> >>=20
> >> word size).=20
> >> * Should it be char or uint8_t? I'm not sure; I'm not really a C++ gur=
u=20
> >> and I mostly ignore the esoteric difference (char is technically only =
7=20
> >> bit, etc.)=20
> >> * Syntax bikeshedding.=20
> >>=20
> >> It's not perfect and all-encompassing, but it is very simple and way=
=20
> >> better than anything we have now.=20
> >>=20
> >> Cheers,=20
> >>=20
> >> Tim=20
> >>=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
> >=20
>

--=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_565_1832469785.1424041116349
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What about using more than one sentence to express your th=
oughts<br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D1=84=D0=B5=D0=B2=
=D1=80=D1=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 23:45:12 UTC+2, Douglas Boffey=
 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">What about using a std::array?
<br>
<br>On 2/15/15, sasho648 &lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"gLGcYCYYOdIJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return=
 true;">sash...@mail.bg</a>&gt; wrote:
<br>&gt; Sorry to disappoint you but people those days doesn't bother with
<br>&gt; meta-programming and thus don't care for it - you're out of luck. =
People
<br>&gt; now days will rather go copy paste the whole file manually or by u=
sing some
<br>&gt;
<br>&gt; external scripting language. Otherwise there is a lot more general=
 solution
<br>&gt;
<br>&gt; for such problems that I had written on ages ago and which involve=
s
<br>&gt; 'constexpr' function and classes for manipulating internal data st=
ructures
<br>&gt; (like creating member names by using common string patterns, editi=
ng
<br>&gt; existing classes, namespaces, creating a lot faster code in which =
is
<br>&gt; determined which will be evaluated on compilation and which should=
 be
<br>&gt; executed and so).
<br>&gt;
<br>&gt; But don't worry - you may not be so unlucky as this proposal seems=
 simple
<br>&gt; enough to be considered.
<br>&gt;
<br>&gt; =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D1=84=D0=B5=D0=B2=D1=80=
=D1=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 20:38:53 UTC+2, <a>tdh...@gmail.com<=
/a> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
<br>&gt;&gt;
<br>&gt;&gt; Hi,
<br>&gt;&gt;
<br>&gt;&gt; Apologies if this has been discussed before. This is something=
 I've wanted
<br>&gt;&gt;
<br>&gt;&gt; in C++ for ages and it seems trivial, so here goes my (first e=
ver)
<br>&gt;&gt; informal
<br>&gt;&gt; proposal. Let me know what you think!
<br>&gt;&gt;
<br>&gt;&gt; # Overview
<br>&gt;&gt;
<br>&gt;&gt; I propose a method for including an external file in a .cpp fi=
le, but
<br>&gt;&gt; instead of copy/pasting code as #include does, it will create =
a char array
<br>&gt;&gt;
<br>&gt;&gt; containing the file contents.
<br>&gt;&gt;
<br>&gt;&gt; # Motivation
<br>&gt;&gt;
<br>&gt;&gt; People have wanted something like this for decades for includi=
ng assets in
<br>&gt;&gt;
<br>&gt;&gt; a binary. Some uses include:
<br>&gt;&gt;
<br>&gt;&gt; * Images
<br>&gt;&gt; * OpenGL shaders
<br>&gt;&gt; * HTML templates
<br>&gt;&gt;
<br>&gt;&gt; The lack of a standard built in, cross platform way to include=
 these has
<br>&gt;&gt; lead to hacks like the XPM image format, and recently this met=
hod using
<br>&gt;&gt; GCC
<br>&gt;&gt; assembly:
<br>&gt;&gt;
<br>&gt;&gt; <a href=3D"https://github.com/graphitemaster/incbin" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.co=
m/url?q\75https%3A%2F%2Fgithub.com%2Fgraphitemaster%2Fincbin\46sa\75D\46snt=
z\0751\46usg\75AFQjCNFF5wq_BomCjXFyZaFvaYHFxns-pg';return true;" onclick=3D=
"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgra=
phitemaster%2Fincbin\46sa\75D\46sntz\0751\46usg\75AFQjCNFF5wq_BomCjXFyZaFva=
YHFxns-pg';return true;">https://github.com/<wbr>graphitemaster/incbin</a>
<br>&gt;&gt;
<br>&gt;&gt; Uses of this include both binary files (which might contain nu=
ll
<br>&gt;&gt; characters) and text files, so the syntax should support both.
<br>&gt;&gt;
<br>&gt;&gt; # Syntax
<br>&gt;&gt;
<br>&gt;&gt; Obviously there are a million different possible syntaxes. I p=
ropose
<br>&gt;&gt; this:
<br>&gt;&gt;
<br>&gt;&gt; &nbsp; &nbsp; #load "shader.vert" main_shader main_shader_len
<br>&gt;&gt;
<br>&gt;&gt; Which works in exactly the same way as #include (i.e. you can =
use ""
<br>&gt;&gt; quotes and &lt;&gt; brackets with the same search path), but t=
he contents of the
<br>&gt;&gt;
<br>&gt;&gt; file are loaded as follows:
<br>&gt;&gt;
<br>&gt;&gt; &nbsp; &nbsp; const char[] main_shader =3D &lt;the contents of=
 the file&gt;;
<br>&gt;&gt; &nbsp; &nbsp; const int main_shader_len =3D &lt;the length of =
the file&gt;;
<br>&gt;&gt;
<br>&gt;&gt; The length variable is optional.
<br>&gt;&gt;
<br>&gt;&gt; # Obvious objections
<br>&gt;&gt;
<br>&gt;&gt; * No way to specify if it is static or not.
<br>&gt;&gt; * No way to specify alignment (it should have a sane default, =
e.g. machine
<br>&gt;&gt;
<br>&gt;&gt; word size).
<br>&gt;&gt; * Should it be char or uint8_t? I'm not sure; I'm not really a=
 C++ guru
<br>&gt;&gt; and I mostly ignore the esoteric difference (char is technical=
ly only 7
<br>&gt;&gt; bit, etc.)
<br>&gt;&gt; * Syntax bikeshedding.
<br>&gt;&gt;
<br>&gt;&gt; It's not perfect and all-encompassing, but it is very simple a=
nd way
<br>&gt;&gt; better than anything we have now.
<br>&gt;&gt;
<br>&gt;&gt; Cheers,
<br>&gt;&gt;
<br>&gt;&gt; Tim
<br>&gt;&gt;
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<br>&gt; "ISO C++ Standard - Future Proposals" group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an
<br>&gt; email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"gLGcYCYYOdIJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">std=
-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"gLGcYCYYOdIJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://=
groups.google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=
=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/=
';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>p=
roposals/</a>.
<br>&gt;
<br></blockquote></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_565_1832469785.1424041116349--
------=_Part_564_1963471541.1424041116349--

.

--Apple-Mail=_265E582A-FA90-4434-9520-04733800A3BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9316, at 2:38 AM, tdhutt@gmail.com wrote:
>=20
> I propose a method for including an external file in a .cpp file, but ins=
tead of copy/pasting code as #include does, it will create a char array con=
taining the file contents.

If I were to express my thoughts in just one sentence, I=E2=80=99d say that=
 an iostreams-compatible resource_stream, such that the implementation can =
transparently store each resource in the main executable or in an associate=
d file, would be more useful than a mechanism guaranteeing memory-resident =
data.

--=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/.

--Apple-Mail=_265E582A-FA90-4434-9520-04733800A3BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9316, at 2:38 AM, <a href=3D"mailto:tdhutt@gmail.com" class=3D"">tdh=
utt@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><div =
class=3D""><div style=3D"font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; line-height: normal; orphans: auto; text-align: start; text-indent: 0px;=
 text-transform: none; white-space: normal; widows: auto; word-spacing: 0px=
; -webkit-text-stroke-width: 0px;" class=3D"">I propose a method for includ=
ing an external file in a .cpp file, but instead of copy/pasting code as #i=
nclude does, it will create a char array containing the file contents.</div=
></div></blockquote></div><br class=3D""><div class=3D"">If I were to expre=
ss my thoughts in just one sentence, I=E2=80=99d say that an iostreams-comp=
atible&nbsp;<font face=3D"Courier" class=3D"">resource_stream</font>, such =
that the implementation can transparently store each resource in the main e=
xecutable or in an associated file, would be more useful than a mechanism g=
uaranteeing memory-resident data.</div></body></html>

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

--Apple-Mail=_265E582A-FA90-4434-9520-04733800A3BE--

.

------=_Part_1361_1906894979.1424067920270
Content-Type: multipart/alternative;
 boundary="----=_Part_1362_137964225.1424067920270"

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

On Sunday, February 15, 2015 at 10:38:53 AM UTC-8, tdh...@gmail.com wrote:
>
>
> Apologies if this has been discussed before. This is something I've wante=
d=20
> in C++ for ages and it seems trivial
>

As you've noticed below ("Obvious objections"), it's not trivial.

=20

> # Overview
>
> I propose a method for including an external file in a .cpp file, but=20
> instead of copy/pasting code as #include does, it will create a char arra=
y=20
> containing the file contents.
>
> # Motivation
>
> People have wanted something like this for decades ...
>
> The lack of a standard built in, cross platform way to include these has=
=20
> lead to hacks like the XPM image format, and recently this method using G=
CC=20
> assembly:=20
>
> https://github.com/graphitemaster/incbin=20
> <https://www.google.com/url?q=3Dhttps%3A%2F%2Fgithub.com%2Fgraphitemaster=
%2Fincbin&sa=3DD&sntz=3D1&usg=3DAFQjCNFF5wq_BomCjXFyZaFvaYHFxns-pg>
>

There's also the standard *nix/BSD utility "xxd".
Seems like the niche is filled. Or, at least, if you want to claim that
(A) XPM
(B) incbin
(C) "xxd -i"
(D) various ad-hoc scripts given in=20
http://stackoverflow.com/questions/8707183/script-tool-to-convert-file-to-c=
-c-source-code-array
....do NOT completely fill this evolutionary niche, and a completely new=20
approach is necessary... well, extraordinary claims require extraordinary=
=20
evidence.


    #load "shader.vert" main_shader main_shader_len
>
> ... It's not perfect and all-encompassing, but it is very simple and way=
=20
> better than anything we have now.
>

Your proposal would have to include at least one example of trying to do=20
something the "old" way (presumably involving an xxd step in your=20
Makefile), identify some problems with the old way, and then show how doing=
=20
it the "new" way solves those problems.

=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_1362_137964225.1424067920270
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, February 15, 2015 at 10:38:53 AM UTC-8, tdh...@=
gmail.com 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"lt=
r"><div><br></div><div>Apologies if this has been discussed before. This is=
 something I've wanted in C++ for ages and it seems trivial</div></div></bl=
ockquote><div><br></div><div>As you've noticed below ("Obvious objections")=
, it's not trivial.</div><div><br></div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div># Overview<br></div><div>=
<br></div><div>I propose a method for including an external file in a .cpp =
file, but instead of copy/pasting code as #include does, it will create a c=
har array containing the file contents.</div><div><br></div><div># Motivati=
on</div><div><br></div><div>People have wanted something like this for deca=
des ...</div><div><br></div><div>The lack of a standard built in, cross pla=
tform way to include these has lead to hacks like the XPM image format, and=
 recently this method using GCC assembly:&nbsp;</div><div><br></div><div><a=
 href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgithub.com%2Fgraphite=
master%2Fincbin&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNFF5wq_BomCjXFyZaFva=
YHFxns-pg" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'h=
ttps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgraphitemaster%2Fi=
ncbin\46sa\75D\46sntz\0751\46usg\75AFQjCNFF5wq_BomCjXFyZaFvaYHFxns-pg';retu=
rn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2=
F%2Fgithub.com%2Fgraphitemaster%2Fincbin\46sa\75D\46sntz\0751\46usg\75AFQjC=
NFF5wq_BomCjXFyZaFvaYHFxns-pg';return true;">https://github.com/<wbr>graphi=
temaster/incbin</a></div></div></blockquote><div><br></div><div>There's als=
o the standard *nix/BSD utility "xxd".</div><div>Seems like the niche is fi=
lled. Or, at least, if you want to claim that</div><div>(A) XPM</div><div>(=
B) incbin</div><div>(C) "xxd -i"</div><div>(D) various ad-hoc scripts given=
 in http://stackoverflow.com/questions/8707183/script-tool-to-convert-file-=
to-c-c-source-code-array</div><div>...do NOT completely fill this evolution=
ary niche, and a completely new approach is necessary... well, extraordinar=
y claims require extraordinary evidence.</div><div><br></div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&nbsp; =
&nbsp; #load "shader.vert" main_shader main_shader_len<br></div><div><br></=
div><div>... It's not perfect and all-encompassing, but it is very simple a=
nd way better than anything we have now.</div></div></blockquote><div><br><=
/div><div>Your proposal would have to include at least one example of tryin=
g to do something the "old" way (presumably involving an xxd step in your M=
akefile), identify some problems with the old way, and then show how doing =
it the "new" way solves those problems.</div><div><br></div><div>=E2=80=93A=
rthur</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_1362_137964225.1424067920270--
------=_Part_1361_1906894979.1424067920270--

.

------=_Part_1723_298674724.1424070973092
Content-Type: multipart/alternative;
 boundary="----=_Part_1724_1156803229.1424070973092"

------=_Part_1724_1156803229.1424070973092
Content-Type: text/plain; charset=UTF-8

This ultimately would encourage a weird sort of resource management
philosophy that I think might be damaging in the long run.

Speaking from experience, it is a tremendously bad idea to bake any
resource into a binary. This includes long string literals meant entirely
for human consumption (error messages, etc. Unless you're using them as
keys for gettext or similar...).

My #1 rule about any non-C++ resource is: It will change sooner and more
frequently than the source code using it.

C++ source files are no place for mesh data, images, or other languages
coded in string literals.

However, I'm not against compiler extensions that would permit the
embedding and semantic checking of shader/compute languages (we already
have _asm).

On most platforms, it is possible to export a symbol and run the image
through tooling that "pastes" the data somewhere in a custom section and
links the aforementioned symbol (like packing icons and sounds in a DOS
image).

--

---
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_1724_1156803229.1424070973092
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This ultimately would encourage a weird sort of resource m=
anagement philosophy that I think might be damaging in the long run.<br><br=
>Speaking from experience, it is a tremendously bad idea to bake any resour=
ce into a binary. This includes long string literals meant entirely for hum=
an consumption (error messages, etc. Unless you're using them as keys for g=
ettext or similar...).<br><br>My #1 rule about any non-C++ resource is: It =
will change sooner and more frequently than the source code using it.<br><b=
r>C++ source files are no place for mesh data, images, or other languages c=
oded in string literals.<br><br>However, I'm not against compiler extension=
s that would permit the embedding and semantic checking of shader/compute l=
anguages (we already have _asm).<br><br>On most platforms, it is possible t=
o export a symbol and run the image through tooling that "pastes" the data =
somewhere in a custom section and links the aforementioned symbol (like pac=
king icons and sounds in a DOS image).<br></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_1724_1156803229.1424070973092--
------=_Part_1723_298674724.1424070973092--

.

On 2015-02-15 13:38, tdhutt@gmail.com wrote:
> I propose this:
>
>     #load "shader.vert" main_shader main_shader_len
>
> Which works in exactly the same way as #include (i.e. you can use "" quotes
> and <> brackets with the same search path), but the contents of the file
> are loaded as follows:
>
>     const char[] main_shader = <the contents of the file>;
>     const int main_shader_len = <the length of the file>;

    constexpr size_t main_shader_len =
      sizeof(main_shader) / sizeof(char);

> The length variable is optional.

Yes... really, *really* optional... as in, there is no case in which you
actually need it, since you can just take the sizeof() the data instead.
(Do note that the type is `size_t` and not `int`!)

> # Obvious objections
>
> * No way to specify if it is static or not.
> * No way to specify alignment (it should have a sane default, e.g. machine
> word size).
> * Should it be char or uint8_t? I'm not sure; I'm not really a C++ guru and
> I mostly ignore the esoteric difference (char is technically only 7 bit,
> etc.)

This could all be solved by having a directive which instead simply
inlines the contents of a file as a string literal:

    static uint8_t const main_shader[] =
    #foo "shader.vert"

(Note: I don't love "load" for this implementation, but not going to
open the naming bikeshed, hence the placeholder directive name.)

As noted above, if you want the length, you can use sizeof() to derive
it, so it is not necessary that the directive itself actually declare
anything.

Another open question is, how do you handle encoding? (Do you? You
definitely want to handle the case of raw bytes, for e.g. image data,
but what about text? Just require that the application be able to
correctly decode it from the raw bytes? Do you ever want to 'load' a
wide string?)

All that said, I'll point out that this is a non-issue for Qt
applications that can simply use Qt's resources for this sort of business.

--
Matthew

--

---
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 2015-02-16 02:16, Chris Gary wrote:
> Speaking from experience, it is a tremendously bad idea to bake any
> resource into a binary. This includes long string literals meant entirely
> for human consumption (error messages, etc. Unless you're using them as
> keys for gettext or similar...).
>
> My #1 rule about any non-C++ resource is: It will change sooner and more
> frequently than the source code using it.
>
> C++ source files are no place for mesh data, images, or other languages
> coded in string literals.

Agreed as far as you specified *source files*, and assuming that you
mean ones containing non-resource-related code. (Also translations, as
these are often developed separate from the application itself.) I can
see where such a tool could easily be misused. On the other hand, it
would be extremely convenient for very simple applications where quality
of code is a lesser concern. More importantly however I'm confident you
could build on such a mechanism to provide an effective resource system
*without the need for additional tools* that would not have problems
here, e.g. having a source file that is *just* resources and some
minimal code (maybe just exporting the symbols) to make them available
to other TU's.

> However, I'm not against compiler extensions that would permit the
> embedding and semantic checking of shader/compute languages (we already
> have _asm).

Who said anything about semantic checking?

> On most platforms, it is possible to export a symbol and run the image
> through tooling that "pastes" the data somewhere in a custom section and
> links the aforementioned symbol (like packing icons and sounds in a DOS
> image).

Okay, I'm confused... above you say "it is a tremendously bad idea to
bake any resource into a binary", but here you are suggesting exactly that?

--
Matthew

--

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

.

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

I find this useless specially in embedded environments since there should
be some processing of the binary data anyway, either before building the
application (in which case the use case goes back to the original "problem"
since an external tool should be invoked by the build system) or later once
the application is running thus consuming time and storing the result in
RAM,
If I'm mistaken, Please show use cases where embedding a binary file
exactly "as is" and without requiring and additional processing.
Maybe the Key question is: what would be the sources of those files to be
embedded?

   Daniel.
El 15/02/2015 15:38, <tdhutt@gmail.com> escribi=C3=B3:

> Hi,
>
> Apologies if this has been discussed before. This is something I've wante=
d
> in C++ for ages and it seems trivial, so here goes my (first ever) inform=
al
> proposal. Let me know what you think!
>
> # Overview
>
> I propose a method for including an external file in a .cpp file, but
> instead of copy/pasting code as #include does, it will create a char arra=
y
> containing the file contents.
>
> # Motivation
>
> People have wanted something like this for decades for including assets i=
n
> a binary. Some uses include:
>
> * Images
> * OpenGL shaders
> * HTML templates
>
> The lack of a standard built in, cross platform way to include these has
> lead to hacks like the XPM image format, and recently this method using G=
CC
> assembly:
>
> https://github.com/graphitemaster/incbin
>
> Uses of this include both binary files (which might contain null
> characters) and text files, so the syntax should support both.
>
> # Syntax
>
> Obviously there are a million different possible syntaxes. I propose this=
:
>
>     #load "shader.vert" main_shader main_shader_len
>
> Which works in exactly the same way as #include (i.e. you can use ""
> quotes and <> brackets with the same search path), but the contents of th=
e
> file are loaded as follows:
>
>     const char[] main_shader =3D <the contents of the file>;
>     const int main_shader_len =3D <the length of the file>;
>
> The length variable is optional.
>
> # Obvious objections
>
> * No way to specify if it is static or not.
> * No way to specify alignment (it should have a sane default, e.g. machin=
e
> word size).
> * Should it be char or uint8_t? I'm not sure; I'm not really a C++ guru
> and I mostly ignore the esoteric difference (char is technically only 7
> bit, etc.)
> * Syntax bikeshedding.
>
> It's not perfect and all-encompassing, but it is very simple and way
> better than anything we have now.
>
> Cheers,
>
> Tim
>
> --
>
> ---
> 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/.

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

<p dir=3D"ltr">I find this useless specially in embedded environments since=
 there should be some processing of the binary data anyway, either before b=
uilding the application (in which case the use case goes back to the origin=
al &quot;problem&quot; since an external tool should be invoked by the buil=
d system) or later once the application is running thus consuming time and =
storing the result in RAM,<br>
If I&#39;m mistaken, Please show use cases where embedding a binary file ex=
actly &quot;as is&quot; and without requiring and additional processing.<br=
>
Maybe the Key question is: what would be the sources of those files to be e=
mbedded?</p>
<p dir=3D"ltr">=C2=A0=C2=A0 Daniel.</p>
<div class=3D"gmail_quote">El 15/02/2015 15:38,  &lt;<a href=3D"mailto:tdhu=
tt@gmail.com">tdhutt@gmail.com</a>&gt; escribi=C3=B3:<br type=3D"attributio=
n"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div>A=
pologies if this has been discussed before. This is something I&#39;ve want=
ed in C++ for ages and it seems trivial, so here goes my (first ever) infor=
mal proposal. Let me know what you think!</div><div><br></div><div># Overvi=
ew<br></div><div><br></div><div>I propose a method for including an externa=
l file in a .cpp file, but instead of copy/pasting code as #include does, i=
t will create a char array containing the file contents.</div><div><br></di=
v><div># Motivation</div><div><br></div><div>People have wanted something l=
ike this for decades for including assets in a binary. Some uses include:</=
div><div><br></div><div>* Images</div><div>* OpenGL shaders</div><div>* HTM=
L templates</div><div><br></div><div>The lack of a standard built in, cross=
 platform way to include these has lead to hacks like the XPM image format,=
 and recently this method using GCC assembly:=C2=A0</div><div><br></div><di=
v><a href=3D"https://github.com/graphitemaster/incbin" target=3D"_blank">ht=
tps://github.com/graphitemaster/incbin</a><br></div><div><br></div><div>Use=
s of this include both binary files (which might contain null characters) a=
nd text files, so the syntax should support both.</div><div><br></div><div>=
# Syntax</div><div><br></div><div>Obviously there are a million different p=
ossible syntaxes. I propose this:</div><div><br></div><div>=C2=A0 =C2=A0 #l=
oad &quot;shader.vert&quot; main_shader main_shader_len</div><div><br></div=
><div>Which works in exactly the same way as #include (i.e. you can use &qu=
ot;&quot; quotes and &lt;&gt; brackets with the same search path), but the =
contents of the file are loaded as follows:</div><div><br></div><div>=C2=A0=
 =C2=A0 const char[] main_shader =3D &lt;the contents of the file&gt;;</div=
><div>=C2=A0 =C2=A0 const int main_shader_len =3D &lt;the length of the fil=
e&gt;;</div><div><br></div><div>The length variable is optional.</div><div>=
<br></div><div># Obvious objections</div><div><br></div><div>* No way to sp=
ecify if it is static or not.</div><div>* No way to specify alignment (it s=
hould have a sane default, e.g. machine word size).</div><div>* Should it b=
e char or uint8_t? I&#39;m not sure; I&#39;m not really a C++ guru and I mo=
stly ignore the esoteric difference (char is technically only 7 bit, etc.)<=
br></div><div>* Syntax bikeshedding.</div><div><br></div><div>It&#39;s not =
perfect and all-encompassing, but it is very simple and way better than any=
thing we have now.</div><div><br></div><div>Cheers,</div><div><br></div><di=
v>Tim</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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></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 />

--047d7b10cb2da54e1a050f36d79d--

.

On 2015-02-16 11:11, dgutson . wrote:
> I find this useless specially in embedded environments since there should
> be some processing of the binary data anyway, either before building the
> application (in which case the use case goes back to the original "problem"
> since an external tool should be invoked by the build system) or later once
> the application is running thus consuming time and storing the result in
> RAM,
> If I'm mistaken, Please show use cases where embedding a binary file
> exactly "as is" and without requiring and additional processing.

Huh? I don't understand your confusion. The OP gave several valid examples.

It's true that embedding e.g. compressed image data will require further
processing before the application can practically use the data, but it's
frequently desirable to punt this to execution time as the trade-off
between an insignificant time to decode the image vs. the reduction in
size of the binary is typically beneficial. (How many image resources do
you know that are saved in uncompressed format these days?) No
build-time processing of the image data is needed; one just needs to
take the raw bytes of the image resource and somehow get them into a
buffer which can (at run time) be fed into the appropriate function to
decode the image.

GLSL shaders are another great example as they *must* be compiled and
linked on the system actually running the code, due to potential
differences in graphics cards / drivers.

Have you truly never seen code like:

  char const[] shader =
  "#version 330\n"
  "int main()\n"
  /* remainder elided */
  ;

....? I certainly have. It's ugly as all else, but it beats having to
write your own file management routines when you lack a proper resource
management system. A proper resource management system (e.g. Qt's qrc)
is much, *MUCH* better. The OP is proposing similar functionality as a
standard feature of the C++ compiler.

Really, if you don't understand why this would be useful, I would
encourage you to look at real world use of existing resource solutions
e.g. qrc / Qt resources. Then ask yourself if it would be useful to have
such a system provided by the compiler rather than depending on external
tools. I rather think that the answer is "yes".

(I actually can't think where you would need additional processing of
the resource files at build time where such processing would logically
fall to a tool that assists with resource embedding. About the only
example that comes to mind is having an SVG that is pre-rendered to a
raster image. But that's like saying that, because there are cases when
source files are generated, we don't need a C++ compiler.)

> Maybe the Key question is: what would be the sources of those files to be
> embedded?

Files on disk, just like any #include's? Maybe I don't understand the
question...

--
Matthew

--

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

.

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

Hi,

Thanks everyone for the feedback! I'm going to summarise it here and give
responses.

* Use std::array or iostream.

Nice idea. Only reason not to do this is it makes things more complicated,
and I thought this proposal might be useful to the C folk too. Std::array
is elegant though, and good point about memory residence.

* No need for a size term - just use sizeof() on the array.

That is a nice idea in theory, but arrays decompose into pointers at the
drop of a hat, and then you lose your size information, e.g. when passed to
functions.

* What's wrong with incbin, using external tools etc?

To be clear, this doesn't let you do anything new, it just makes it easier.
There are already tons of things in C++ that are just conveniences so that
isn't a real objection.

* Use a proper resource system!

That's overkill for many things, and is often not available.

* Don't see a need for this.

I've given clear examples of where there is definitely a need. The
existence of incbin proves it. Incbin has 77 stars and 5 forks in less than
two weeks. As Matthew Woehlke mentioned it is easy to find code that would
benefit from this.

So based on the feedback it seems like people think this is generally a
good idea, but the debate is over how it will work. After considering the
options I think Matthew's proposal of

    static uint8_t const main_shader[] =
    #load "shader.vert"

is onto something. It allows you to specify the format (uint8_t vs char)
and linkage of the variable. If it expands to `{0x50, 0x51, ... }` then
this can also work with std::vector, and std::string, although I can't see
a way to make it work with std::array because that requires the size in a
template argument.

The syntax is kind of ugly though, especially with them on the different
lines and with no semicolon. Maybe the preprocessor is the wrong place for
this. I don't think you could do this:

    const uint8_t main_shader[] = #load "shader.vert"
    const std::vector<uint8_t> main_shader = #load "shader.vert"
    const std::string main_shader = #load "shader.vert"

Maybe you could do this

    #load "shader.vert" SHADER_SOURCE_LITERAL
    const std::string main_shader = SHADER_SOURCE_LITERAL;

SHADER_SOURCE_LITERAL would be replaced with {0x50, 0x51, 0x52, ...} (or
whatever the file contains).

Can anyone think of a better syntax?

Cheers,

Tim

--

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

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

<div dir=3D"ltr"><p dir=3D"ltr">Hi,</p>
<p dir=3D"ltr">Thanks everyone for the feedback! I&#39;m going to summarise=
 it here and give responses.</p><p dir=3D"ltr">* Use std::array or iostream=
..<br></p>
<p dir=3D"ltr">Nice idea. Only reason not to do this is it makes things mor=
e complicated, and I thought this proposal might be useful to the C folk to=
o. Std::array is elegant though, and good point about memory residence.</p>=
<p>* No need for a size term - just use sizeof() on the array.</p><p>That i=
s a nice idea in theory, but arrays decompose into pointers at the drop of =
a hat, and then you lose your size information, e.g. when passed to functio=
ns.</p>
<p dir=3D"ltr">* What&#39;s wrong with incbin, using external tools etc?</p=
>
<p dir=3D"ltr">To be clear, this doesn&#39;t let you do anything new, it ju=
st makes it easier. There are already tons of things in C++ that are just c=
onveniences so that isn&#39;t a real objection.</p><p>* Use a proper resour=
ce system!</p><p>That&#39;s overkill for many things, and is often not avai=
lable.</p><p>* Don&#39;t see a need for this.</p><p>I&#39;ve given clear ex=
amples of where there is definitely a need. The existence of incbin proves =
it. Incbin has 77 stars and 5 forks in less than two weeks. As Matthew Woeh=
lke mentioned it is easy to find code that would benefit from this.</p>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">So based on=
 the feedback it seems like people think this is generally a good idea, but=
 the debate is over how it will work. After considering the options I think=
 Matthew&#39;s proposal of</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">=C2=A0 =C2=A0 static uint8_t const main_shader[] =3D=
=C2=A0</div><div class=3D"gmail_quote">=C2=A0 =C2=A0 #load &quot;shader.ver=
t&quot;</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote=
">is onto something. It allows you to specify the format (uint8_t vs char) =
and linkage of the variable. If it expands to `{0x50, 0x51, ... }` then thi=
s can also work with std::vector, and std::string, although I can&#39;t see=
 a way to make it work with std::array because that requires the size in a =
template argument.</div><div class=3D"gmail_quote"><br></div><div class=3D"=
gmail_quote">The syntax is kind of ugly though, especially with them on the=
 different lines and with no semicolon. Maybe the preprocessor is the wrong=
 place for this. I don&#39;t think you could do this:</div><div class=3D"gm=
ail_quote"><br></div><div class=3D"gmail_quote">=C2=A0 =C2=A0 const uint8_t=
 main_shader[] =3D #load &quot;shader.vert&quot;</div><div class=3D"gmail_q=
uote"><div class=3D"gmail_quote">=C2=A0 =C2=A0 const std::vector&lt;uint8_t=
&gt; main_shader =3D #load &quot;shader.vert&quot;</div><div><div class=3D"=
gmail_quote">=C2=A0 =C2=A0 const std::string main_shader =3D #load &quot;sh=
ader.vert&quot;</div></div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">Maybe you could do this</div><div class=3D"gmail_quote"><b=
r></div><div class=3D"gmail_quote">=C2=A0 =C2=A0 #load &quot;shader.vert&qu=
ot; SHADER_SOURCE_LITERAL</div><div class=3D"gmail_quote">=C2=A0 =C2=A0 con=
st std::string main_shader =3D SHADER_SOURCE_LITERAL;</div><div class=3D"gm=
ail_quote"><br></div><div class=3D"gmail_quote">SHADER_SOURCE_LITERAL would=
 be replaced with {0x50, 0x51, 0x52, ...} (or whatever the file contains).<=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Can an=
yone think of a better syntax?</div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">Tim</div><div><br></div></div><div class=3D"gmai=
l_quote"><br></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 />

--047d7b5d44c6d357eb050f3b3ce4--

.

On 2015-02-16 16:26, Tim Hutt wrote:
> * No need for a size term - just use sizeof() on the array.
>
> That is a nice idea in theory, but arrays decompose into pointers at the
> drop of a hat, and then you lose your size information, e.g. when passed to
> functions.

The intent / expectation was to take the sizeof() at the point of
variable declaration :-).

> [various other points]

Eliding the other points, but FWIW I agree with most of them. Resources
are *vital* to many projects. Sure, there are external tools, but that
way lies inconsistency and inconvenience.

> So based on the feedback it seems like people think this is generally a
> good idea, but the debate is over how it will work. After considering the
> options I think Matthew's proposal of
>
>     static uint8_t const main_shader[] =
>     #load "shader.vert"
>
> is onto something. It allows you to specify the format (uint8_t vs char)
> and linkage of the variable. If it expands to `{0x50, 0x51, ... }` then
> this can also work with std::vector, and std::string, although I can't see
> a way to make it work with std::array because that requires the size in a
> template argument.

Hmm... that's a really great idea, but I'm not sure if it's ideal. The
trouble is that a string literal decomposes into a char*, while an
initializer_list (effectively what you're suggesting) I'm pretty sure
does not. In particular, I could imagine this being limiting with
libraries that can't construct a string type from an initializer_list.
That said, I think both have their uses; maybe the syntax should allow
specifying which is wanted? (And if not... I think I agree that the
initializer_list is more generally useful in modern code.)

I think with make_array, you could use the initializer_list to create a
std::array.

> The syntax is kind of ugly though, especially with them on the different
> lines and with no semicolon.

Actually, you forgot the ';', above :-). (Um... and I forgot it in my
example. Could've sworn I had one, too... it may have been accidentally
lost in editing. Sorry about that.)

Maybe something like __pragma, i.e. a preprocessor directive but NOT a
'#' directive, would be better?

> Maybe you could do this
>
>     #load "shader.vert" SHADER_SOURCE_LITERAL
>     const std::string main_shader = SHADER_SOURCE_LITERAL;

....or that. I could see that as being similar to '#define' (in which
case I might suggest having the identifier precede the file name... or
not; consistency aside, your order works better from an English grammar
POV).

I like either one. The __pragma-like doesn't introduce a PP symbol, but
that can go either way (namespace pollution vs. ease of reuse).

--
Matthew

--

---
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 Monday 16 February 2015 17:10:50 Matthew Woehlke wrote:
> > is onto something. It allows you to specify the format (uint8_t vs char)
> > and linkage of the variable. If it expands to `{0x50, 0x51, ... }` then
> > this can also work with std::vector, and std::string, although I can't see
> > a way to make it work with std::array because that requires the size in a
> > template argument.
>
> Hmm... that's a really great idea, but I'm not sure if it's ideal. The
> trouble is that a string literal decomposes into a char*, while an
> initializer_list (effectively what you're suggesting) I'm pretty sure
> does not. In particular, I could imagine this being limiting with
> libraries that can't construct a string type from an initializer_list.
> That said, I think both have their uses; maybe the syntax should allow
> specifying which is wanted? (And if not... I think I agree that the
> initializer_list is more generally useful in modern code.)

Two questions:

a) why would you store the array into anything except a static const array or
a template type that is equivalent to that? If the template type takes an
array by reference, it doesn't matter if the string was "foo" or
{'f', 'o', 'o', 0}

b) why would the underlying element type be anything other than char?

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

.

--Apple-Mail=_A77B396C-7C43-4573-B3EC-117E3F64BA80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9317, at 8:46 AM, Thiago Macieira <thiago@maciei=
ra.org <mailto:thiago@macieira.org>> wrote:
>=20
> a) why would you store the array into anything except a static const arra=
y or=20
> a template type that is equivalent to that? If the template type takes an=
=20
> array by reference, it doesn't matter if the string was "foo" or=20
> {'f', 'o', 'o', 0}

For large resources, it=E2=80=99s seldom practical to load them all before =
main starts. Although virtual memory and shared libraries can help alleviat=
e the pain, the tried-and-true solution is to load resource files at runtim=
e. Embedded systems with little RAM and no VM might have no choice.

Serializing initializer lists is an interesting thought, but I think that p=
roblem is orthogonal to the means of storage. You can=E2=80=99t serialize a=
 std::initializer_list of non-serializable objects. However, initializer_li=
st over serializable types could be a useful intermediary for real containe=
rs and such. Perhaps some clever runtime could parse a standard text (or co=
mpressed binary) format back to initializer_list and mixed-aggregate nodes =
and call the correct constructors as if they all formed a braced-init-list.=
 The other piece of the puzzle is serialization.

In any case, once the initializer_list has been used, you might as well unl=
oad it. With static storage, that means falling back on VM.

Actually, for large resources on small systems, putting all the initializer=
s in RAM is too inefficient. Range iterables would be a better solution, pe=
rhaps providing the efficiency of streams (minus the inefficiency of <iostr=
eam>) with the convenience of initializer lists.

> b) why would the underlying element type be anything other than char?

Some string processing prefers wide characters. Numeric sequences might be =
stored as binary. I think it=E2=80=99s better to simplify conversion than t=
o change the underlying type, though.

--=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/.

--Apple-Mail=_A77B396C-7C43-4573-B3EC-117E3F64BA80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><div c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=
=80=9302=E2=80=9317, at 8:46 AM, Thiago Macieira &lt;<a href=3D"mailto:thia=
go@macieira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br cla=
ss=3D"Apple-interchange-newline"><div class=3D"">a) why would you store the=
 array into anything except a static const array or <br class=3D"">a templa=
te type that is equivalent to that? If the template type takes an <br class=
=3D"">array by reference, it doesn't matter if the string was "foo" or <br =
class=3D"">{'f', 'o', 'o', 0}<br class=3D""></div></blockquote><div class=
=3D""><br class=3D""></div><div class=3D"">For large resources, it=E2=80=99=
s seldom practical to load them all before <font face=3D"Courier" class=3D"=
">main</font> starts. Although virtual memory and shared libraries can help=
 alleviate the pain, the tried-and-true solution is to load resource files =
at runtime. Embedded systems with little RAM and no VM might have no choice=
..</div><div class=3D""><br class=3D""></div><div class=3D"">Serializing ini=
tializer lists&nbsp;is an interesting thought, but I think that problem is =
orthogonal to the means of storage. You can=E2=80=99t serialize a <font fac=
e=3D"Courier" class=3D"">std::initializer_list</font> of non-serializable o=
bjects. However, <font face=3D"Courier" class=3D"">initializer_list</font> =
over serializable types could be a useful intermediary for real containers =
and such. Perhaps some clever runtime could parse a standard text (or compr=
essed binary) format back to <font face=3D"Courier" class=3D"">initializer_=
list</font>&nbsp;and mixed-aggregate nodes and call the correct constructor=
s as if they all formed a <i class=3D"">braced-init-list</i>. The other pie=
ce of the puzzle is serialization.</div><div class=3D""><br class=3D""></di=
v><div class=3D"">In any case, once the <font face=3D"Courier" class=3D"">i=
nitializer_list</font> has been used, you might as well unload it. With sta=
tic storage, that means falling back on VM.</div><div class=3D""><br class=
=3D""></div><div class=3D"">Actually, for large resources on small systems,=
 putting all the initializers in RAM is too inefficient. Range iterables wo=
uld be a better solution, perhaps providing the efficiency of streams (minu=
s the inefficiency of <font face=3D"Courier" class=3D"">&lt;iostream&gt;</f=
ont>) with the convenience of initializer lists.</div><br class=3D""><block=
quote type=3D"cite" class=3D""><div class=3D"">b) why would the underlying =
element type be anything other than char?<br class=3D""></div></blockquote>=
<div class=3D""><br class=3D""></div><div class=3D"">Some string processing=
 prefers wide characters. Numeric sequences might be stored as binary.&nbsp=
;I think it=E2=80=99s better to simplify conversion than to change the unde=
rlying type, though.</div></div></body></html>

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

--Apple-Mail=_A77B396C-7C43-4573-B3EC-117E3F64BA80--

.

On Tuesday 17 February 2015 09:29:15 David Krauss wrote:
> > On 2015=E2=80=9302=E2=80=9317, at 8:46 AM, Thiago Macieira <thiago@maci=
eira.org
> > <mailto:thiago@macieira.org>> wrote:
> >=20
> > a) why would you store the array into anything except a static const ar=
ray
> > or a template type that is equivalent to that? If the template type tak=
es
> > an array by reference, it doesn't matter if the string was "foo" or
> > {'f', 'o', 'o', 0}
>=20
> For large resources, it=E2=80=99s seldom practical to load them all befor=
e main
> starts. Although virtual memory and shared libraries can help alleviate t=
he
> pain, the tried-and-true solution is to load resource files at runtime.
> Embedded systems with little RAM and no VM might have no choice.

Agreed, which means they are unlikely to use this functionality at all.=20

On systems with no VM and little RAM, the resource data would be stored in=
=20
some type of mass storage that doesn't get loaded with the executable. Beca=
use=20
it's outside the executable, it's outside the compiler's scope and therefor=
e=20
we're not talking about this feature.

I didn't understand the rest of your comment.

> > b) why would the underlying element type be anything other than char?
>=20
> Some string processing prefers wide characters. Numeric sequences might b=
e
> stored as binary. I think it=E2=80=99s better to simplify conversion than=
 to change
> the underlying type, though.

The file on disk is composed of bytes. Are we expecting the compiler will=
=20
translate from bytes (char) to bigger data types? If so, how to specify the=
=20
endian order?

I think that, at most, the compiler would load the byte data and store as-i=
s=20
in the binary image, with no conversion. If you use #load with wchar_t, you=
=20
should make sure that your data file has the right size and endianness.

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

--=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 2015=E2=80=9302=E2=80=9317, at 11:06 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> On Tuesday 17 February 2015 09:29:15 David Krauss wrote:
>> the tried-and-true solution is to load resource files at runtime.
>> Embedded systems with little RAM and no VM might have no choice.
>=20
> Agreed, which means they are unlikely to use this functionality at all.=
=20
>=20
> On systems with no VM and little RAM, the resource data would be stored i=
n=20
> some type of mass storage that doesn't get loaded with the executable. Be=
cause=20
> it's outside the executable, it's outside the compiler's scope and theref=
ore=20
> we're not talking about this feature.
>=20
> I didn't understand the rest of your comment.

These days, most vendors provide build systems that do handle assets. It=E2=
=80=99s reasonable to specify some system for retrieving named source-file =
resources as streams, and let vendors decide how to do the baking.

Portable libraries are currently restricted to resources baked into the C++=
 source code. That=E2=80=99s the fundamental problem getting attacked here.=
 It=E2=80=99s a fallacy to say that a C++ compiler must be restricted to pr=
oducing one executable file, and therefore no more efficient solution is vi=
able. Even if you accept that, there are still two solutions that allow a d=
umb compiler: bake-in all the resources, or bake-in none and let the build =
system copy them to a local subdirectory known to the runtime library. Thes=
e are already widely implemented on embedded and hosted systems, respective=
ly.

>> Some string processing prefers wide characters. Numeric sequences might =
be
>> stored as binary. I think it=E2=80=99s better to simplify conversion tha=
n to change
>> the underlying type, though.
>=20
> The file on disk is composed of bytes. Are we expecting the compiler will=
=20
> translate from bytes (char) to bigger data types? If so, how to specify t=
he=20
> endian order?

Endian order doesn=E2=80=99t need to be specified for resource files any mo=
re than it does for executable files. They are subordinate to the executabl=
e, ideally hidden from the user, and typically not removed or installed exc=
ept by the executable or its dedicated updater. Of course, a platform can d=
efine a binary format. Mac OS has gone through several iterations =E2=80=94=
 its original =E2=80=9CResource Manager=E2=80=9D was instrumental to gettin=
g inexperienced vendors to fit GUI apps into a minuscule machine. Ideally C=
++ can provide a portable interface to platform-specific resource formats.

> I think that, at most, the compiler would load the byte data and store as=
-is=20
> in the binary image, with no conversion. If you use #load with wchar_t, y=
ou=20
> should make sure that your data file has the right size and endianness.

We can do better than hacking assembler behavior into the preprocessor.

--=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_1345_1560541101.1424147921095
Content-Type: multipart/alternative;
 boundary="----=_Part_1346_796503696.1424147921095"

------=_Part_1346_796503696.1424147921095
Content-Type: text/plain; charset=UTF-8



> Okay, I'm confused... above you say "it is a tremendously bad idea to
> bake any resource into a binary", but here you are suggesting exactly
> that?
>

Its still a bad idea (have to distribute a patch for a change of icon).
Just pointing out that its been done.

Who said anything about semantic checking?


I meant to say "syntax checking", though "semantic" still applies here
(e.g. CUDA extensions). More important than "it just compiling" is "it not
compiling when it shouldn't work."

*snip* On the other hand, it would be extremely convenient for very simple
> applications where quality of code is a lesser concern. More importantly
> however I'm confident you could build on such a mechanism to provide an
> effective resource system *without the need for additional tools* that
> would not have problems here, e.g. having a source file that is *just*
> resources and some minimal code (maybe just exporting the symbols) to make
> them available to other TU's


Simple applications notwithstanding, this is a toolchain problem. Pursuing
standardization of resource management in general would require a more
thorough examination of this domain than proposing simple data inclusion --
we are still being bitten by similar shortsightedness with "#include" now
several decades after the fact.

--

---
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_1346_796503696.1424147921095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&nbsp;</div><blockquote style=3D"margin: 0px 0px 0px =
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=
=3D"gmail_quote">Okay, I'm confused... above you say "it is a tremendously =
bad idea to
<br>bake any resource into a binary", but here you are suggesting exactly t=
hat?
<br></blockquote><div>&nbsp;</div>Its still a bad idea (have to distribute =
a patch for a change of icon). Just pointing out that its been done.<br><br=
><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb=
(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Who said anythin=
g about semantic checking?
</blockquote><br>I meant to say "syntax checking", though "semantic" still =
applies here (e.g. CUDA extensions). More important than "it just compiling=
" is "it not compiling when it shouldn't work."<br><br><blockquote style=3D=
"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padd=
ing-left: 1ex;" class=3D"gmail_quote">*snip* On the other hand, it would be=
 extremely convenient for very simple applications where quality of code is=
 a lesser concern. More importantly however I'm confident you
could build on such a mechanism to provide an effective resource system
*without the need for additional tools* that would not have problems here, =
e.g. having a source file that is *just* resources and some minimal code (m=
aybe just exporting the symbols) to make them available to other TU's
</blockquote><div><br>Simple applications notwithstanding, this is a toolch=
ain problem. Pursuing standardization of resource management in general wou=
ld require a more thorough examination of this domain than proposing simple=
 data inclusion -- we are still being bitten by similar shortsightedness wi=
th "#include" now several decades after the fact.<br></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_1346_796503696.1424147921095--
------=_Part_1345_1560541101.1424147921095--

.

On Tuesday 17 February 2015 11:46:19 David Krauss wrote:
> > The file on disk is composed of bytes. Are we expecting the compiler wi=
ll=20
> > translate from bytes (char) to bigger data types? If so, how to specify
> > the  endian order?
>=20
> Endian order doesn=E2=80=99t need to be specified for resource files any =
more than
> it does for executable files. They are subordinate to the executable,
> ideally hidden from the user, and typically not removed or installed exce=
pt
> by the executable or its dedicated updater. Of course, a platform can
> define a binary format. Mac OS has gone through several iterations =E2=80=
=94 its
> original =E2=80=9CResource Manager=E2=80=9D was instrumental to getting i=
nexperienced
> vendors to fit GUI apps into a minuscule machine. Ideally C++ can provide=
 a
> portable interface to platform-specific resource formats.

The problem is that the file containing binary data may also be intended to=
 be=20
portable, so it may contain data in a specific endianness. When compiled to=
 a=20
target with a different endianness, the compiler could be expected to swap=
=20
things around.

Which is why I am saying this feature, if adopted, should be restricted to =
1-
byte entities. That also resolves the question of whether to return a=20
character literal or an initializer list: since they are the same, a charac=
ter=20
literal is easier to understand.
--=20
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

--=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 Monday 16 February 2015 20:38:41 Chris Gary wrote:
> > Okay, I'm confused... above you say "it is a tremendously bad idea to
> > bake any resource into a binary", but here you are suggesting exactly
> > that?
>
>
> Its still a bad idea (have to distribute a patch for a change of icon).
> Just pointing out that its been done.

Does it make a difference if it's a separate file or the same as the executable
if the only way to get anything changed on the device is to flash it with a new
image?

Please don't generalise: what might be a bad idea for some scenarios may be
perfectly acceptable for others.

--
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_198_974917418.1424151359335
Content-Type: multipart/alternative;
 boundary="----=_Part_199_136817716.1424151359336"

------=_Part_199_136817716.1424151359336
Content-Type: text/plain; charset=UTF-8


>
>  Does it make a difference if it's a separate file or the same as the
> executable
> if the only way to get anything changed on the device is to flash it with
> a new
> image?
>
> Please don't generalise: what might be a bad idea for some scenarios may
> be
> perfectly acceptable for others.


You are correct: No single approach or ideology is universally applicable.

I'm not generalizing here. Just try to define "resource" and "access
thereto."

I call it a "bad idea" in the sense of mixing concerns. This is
fundamentally a toolchain/platform problem.

Attempting to standardize such a thing at this time seems foolhardy,
especially through a preprocessor facility.

It would be nice to have a comparison of all resource management
tools/philosophies presently in common use and for what platforms they are
used.

Everyone can legitimately start arguing about benefits/correctness from
there.

--

---
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_199_136817716.1424151359336
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
&nbsp;Does it make a difference if it's a separate file or the same as the =
executable=20
<br>if the only way to get anything changed on the device is to flash it wi=
th a new=20
<br>image?
<br>
<br>Please don't generalise: what might be a bad idea for some scenarios ma=
y be=20
<br>perfectly acceptable for others.
</blockquote><br><div>You are correct: No single approach or ideology is un=
iversally applicable.<br><br></div>I'm not generalizing here. Just try to d=
efine "resource" and "access thereto."<br><br>I
 call it a "bad idea" in the sense of mixing concerns. This is=20
fundamentally a toolchain/platform problem.<br><br>Attempting to standardiz=
e such a thing at this time seems foolhardy, especially through a preproces=
sor facility.<br><br>It would be nice to have a comparison of all resource =
management tools/philosophies presently in common use and for what platform=
s they are used.<br><br>Everyone can legitimately start arguing about benef=
its/correctness from there.<br></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_199_136817716.1424151359336--
------=_Part_198_974917418.1424151359335--

.

------=_Part_2058_722817938.1424152663950
Content-Type: multipart/alternative;
 boundary="----=_Part_2059_86092887.1424152663951"

------=_Part_2059_86092887.1424152663951
Content-Type: text/plain; charset=UTF-8



On Monday, February 16, 2015 at 2:26:23 PM UTC-7, Tim Hutt wrote:
>
> *snip*
>


> Can anyone think of a better syntax?
>
> Cheers,
>
> Tim
>

How about attributes?


[[from_file("shader.vert")]] // Perhaps use the same lookup rules as
#include
extern const char src[];    // Size is computed when sizeof() is applied:
"shader.vert" is loaded and measured. Linker deals with the data later...





--

---
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_2059_86092887.1424152663951
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, February 16, 2015 at 2:26:23 PM UTC-7, =
Tim Hutt 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=
"><div class=3D"gmail_quote"><div class=3D"gmail_quote">*snip*<br></div></d=
iv></div></blockquote><div>&nbsp;</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div class=3D"gmail_qu=
ote"></div><div class=3D"gmail_quote">Can anyone think of a better syntax?<=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers=
,</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Tim<=
/div></div></div></blockquote><div><br>How about attributes?<br><br><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">from_file</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">"shader.vert"</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)]]</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// Perhaps use the same lookup rules as #include</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">extern</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">char</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> src</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">[];</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> &nbsp; &nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// Size is computed when sizeof() is applied: "shader.vert" is loa=
ded and measured. Linker deals with the data later...</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><br>=
&nbsp;<br></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_2059_86092887.1424152663951--
------=_Part_2058_722817938.1424152663950--

.

--Apple-Mail=_12D3012F-AFB8-40DC-BC81-BA79CEA293FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9317, at 12:43 PM, Thiago Macieira <thiago@macie=
ira.org <mailto:thiago@macieira.org>> wrote:
>=20
> The problem is that the file containing binary data may also be intended =
to be=20
> portable, so it may contain data in a specific endianness.

There are source files and there are installable build products. Source fil=
es should be portable, and the proposal does concern binary source files (w=
hich are usually called =E2=80=9Cassets=E2=80=9D instead). Though installed=
 asset files might be identical copies of source files, they=E2=80=99re not=
 portable.

When I say =E2=80=9Cresource files=E2=80=9D there, I mean something which i=
s already a build product. Looking again at the Mac OS, its original Resour=
ce Manager dealt with =E2=80=9Cresources=E2=80=9D which were baked byte-str=
ings stored in the =E2=80=9Cresource fork=E2=80=9D of an executable file an=
d loaded on demand. Such resources were often specified in textual source f=
iles but distributed in binary. Today, the formats and interfaces have chan=
ged, and OS X makes resources look more like regular files, but the build t=
ools and filesystem still cooperate for the sake of data compression.

> When compiled to a=20
> target with a different endianness, the compiler could be expected to swa=
p=20
> things around.

My main suggestion is that C++ should provide function that returns a named=
 resource as a std::istream. Then the programmer chooses between text and p=
latform-specific endianness, and the platform build system chooses between =
storage in the executable, in a separate file, in a file aggregating variou=
s resources, etc.

For assets in standard formats like PNG, the build system should also be ab=
le intervene so the resource isn=E2=80=99t exactly the same as the source f=
ile. This means that it would be overspecification to say that the resource=
 is defined exactly by the file contents. It=E2=80=99s sufficient to say th=
at a string constant identifies a resource, similarly to a header file, and=
 that the istream provides the resource contents.

A secondary suggestion is that C++ should provide a standard class for bake=
d, opaque representation of nested, constant initializer lists. Runtime cla=
sses representing resources can initialize from such an object. (Constexpr =
is a requirement of initialization, but access is not constexpr.) The progr=
ammer has no control over the binary format, but the platform build system =
can choose whether to optimize it, and whether to store it in a separate up=
datable file despite the possible presence of endian-specific formatting.

For now, let=E2=80=99s stick to the primary suggestion.

> Which is why I am saying this feature, if adopted, should be restricted t=
o 1-
> byte entities. That also resolves the question of whether to return a=20
> character literal or an initializer list: since they are the same, a char=
acter=20
> literal is easier to understand.

I=E2=80=99m not sure what you mean by =E2=80=9Creturn a character literal.=
=E2=80=9D

String literals have size fixed at compile time, but you=E2=80=99re talking=
 about replacing the underlying file. If you mean to return char*, then the=
 assumption of null termination is too restrictive. We need the size of the=
 byte-string, which implies the complexity of initializer_list. But if it=
=E2=80=99s ever going to be reliably unloaded, it needs to be on the heap, =
which bumps the requirement up to std::string.

The next step is std::stringstream. I think iostreams is a more viable inte=
rface, and it represents less implementation effort, because the platform c=
an forgo all of this. The build system copies the file to a dedicated direc=
tory, the runtime library opens it and returns an ifstream. Implementation =
complete!


> On 2015=E2=80=9302=E2=80=9317, at 12:45 PM, Thiago Macieira <thiago@macie=
ira.org <mailto:thiago@macieira.org>> wrote:
>=20
> Does it make a difference if it's a separate file or the same as the exec=
utable=20
> if the only way to get anything changed on the device is to flash it with=
 a new=20
> image?

The platforms standing to benefit are a vast majority. Even minimalist embe=
dded pseudo-filesystems can provide facilities for partial updates. Anyway,=
 standardization of a feature for updatable programs wouldn=E2=80=99t lock =
out platforms lacking dedicated updaters.

=E2=80=9CUpdatable programs.=E2=80=9D That has a nice ring to it.

--=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/.

--Apple-Mail=_12D3012F-AFB8-40DC-BC81-BA79CEA293FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><div c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=
=80=9302=E2=80=9317, at 12:43 PM, Thiago Macieira &lt;<a href=3D"mailto:thi=
ago@macieira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D"">The problem is that the f=
ile containing binary data may also be intended to be <br class=3D"">portab=
le, so it may contain data in a specific endianness. </div></blockquote><di=
v class=3D""><br class=3D""></div><div class=3D"">There are source files an=
d there are installable build products. Source files should be portable, an=
d the proposal does concern binary source files (which are usually called =
=E2=80=9Cassets=E2=80=9D instead). Though installed asset files might be id=
entical copies of source files, they=E2=80=99re not portable.</div><div cla=
ss=3D""><br class=3D""></div><div class=3D"">When I say =E2=80=9Cresource f=
iles=E2=80=9D there, I mean something which is already a build product. Loo=
king again at the Mac OS, its original Resource Manager dealt with =E2=80=
=9Cresources=E2=80=9D which were baked byte-strings stored in the =E2=80=9C=
resource fork=E2=80=9D of an executable file and loaded on demand. Such res=
ources were often specified in textual source files but distributed in bina=
ry. Today, the formats and interfaces have changed, and OS X makes resource=
s look more like regular files, but the build tools and filesystem still co=
operate for the sake of data compression.</div><div class=3D""><br class=3D=
""></div><blockquote type=3D"cite" class=3D""><div class=3D"">When compiled=
 to a <br class=3D"">target with a different endianness, the compiler could=
 be expected to swap <br class=3D"">things around.<br class=3D""></div></bl=
ockquote><div class=3D""><br class=3D""></div><div class=3D""><div class=3D=
"">My main suggestion is that C++ should provide function that returns a na=
med resource as a <font face=3D"Courier" class=3D"">std::istream</font>. Th=
en the programmer chooses between text and platform-specific endianness, an=
d the platform build system chooses between storage in the executable, in a=
 separate file, in a file aggregating various resources, etc.</div><div cla=
ss=3D""><br class=3D""></div><div class=3D"">For assets in standard formats=
 like PNG, the build system should also be able intervene so the resource i=
sn=E2=80=99t exactly the same as the source file. This means that it would =
be overspecification to say that the resource is defined exactly by the fil=
e contents. It=E2=80=99s sufficient to say that a string constant identifie=
s a resource, similarly to a header file, and that the <font face=3D"Courie=
r" class=3D"">istream</font> provides the resource contents.</div><div clas=
s=3D""><br class=3D""></div><div class=3D"">A secondary suggestion is that =
C++ should provide a standard class for baked, opaque representation of nes=
ted, constant initializer lists. Runtime classes representing resources can=
 initialize from such an object. (Constexpr is a requirement of initializat=
ion, but access is not constexpr.) The programmer has no control over the b=
inary format, but the platform build system can choose whether to optimize =
it, and whether to store it in a separate updatable file despite the possib=
le presence of endian-specific formatting.</div><div class=3D""><br class=
=3D""></div><div class=3D"">For now, let=E2=80=99s stick to the primary sug=
gestion.</div><div class=3D""><br class=3D""></div></div><blockquote type=
=3D"cite" class=3D""><div class=3D"">Which is why I am saying this feature,=
 if adopted, should be restricted to 1-<br class=3D"">byte entities. That a=
lso resolves the question of whether to return a <br class=3D"">character l=
iteral or an initializer list: since they are the same, a character <br cla=
ss=3D"">literal is easier to understand.<br class=3D""></div></blockquote><=
div class=3D""><br class=3D""></div><div class=3D"">I=E2=80=99m not sure wh=
at you mean by =E2=80=9Creturn a character literal.=E2=80=9D</div><div clas=
s=3D""><br class=3D""></div></div>String literals have size fixed at compil=
e time, but you=E2=80=99re talking about replacing the underlying file. If =
you mean to return <font face=3D"Courier" class=3D"">char*</font>, then the=
 assumption of null termination is too restrictive. We need the size of the=
 byte-string, which implies the complexity of <font face=3D"Courier" class=
=3D"">initializer_list</font>. But if it=E2=80=99s ever going to be reliabl=
y unloaded, it needs to be on the heap, which bumps the requirement up to&n=
bsp;<font face=3D"Courier" class=3D"">std::string</font>.<div class=3D""><b=
r class=3D""></div><div class=3D"">The next step is <font face=3D"Courier" =
class=3D"">std::stringstream</font>. I think iostreams is a more viable int=
erface, and it represents less implementation effort, because the platform =
can forgo all of this. The build system copies the file to a dedicated dire=
ctory, the runtime library opens it and returns an <font face=3D"Courier" c=
lass=3D"">ifstream</font>. Implementation complete!</div><div class=3D""><b=
r class=3D""></div><div class=3D""><br class=3D""></div><div class=3D""><bl=
ockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=E2=80=
=9317, at 12:45 PM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.o=
rg" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><div class=3D""><span class=3D"" style=3D"float: none; =
display: inline !important;">Does it make a difference if it's a separate f=
ile or the same as the executable&nbsp;</span><br class=3D""><span class=3D=
"" style=3D"float: none; display: inline !important;">if the only way to ge=
t anything changed on the device is to flash it with a new&nbsp;</span><br =
class=3D""><span class=3D"" style=3D"float: none; display: inline !importan=
t;">image?</span><br class=3D""></div></blockquote><br class=3D""></div><di=
v class=3D"">The platforms standing to benefit are a vast majority. Even mi=
nimalist embedded pseudo-filesystems can provide facilities for partial upd=
ates. Anyway, standardization of a feature for updatable programs wouldn=E2=
=80=99t lock out platforms lacking dedicated updaters.</div><div class=3D""=
><br class=3D""></div><div class=3D"">=E2=80=9CUpdatable programs.=E2=80=9D=
 That has a nice ring to it.</div></body></html>

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

--Apple-Mail=_12D3012F-AFB8-40DC-BC81-BA79CEA293FB--

.

------=_Part_2492_715929896.1424155711798
Content-Type: multipart/alternative;
 boundary="----=_Part_2493_282887931.1424155711798"

------=_Part_2493_282887931.1424155711798
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 17, 2015 at 3:57:44 AM UTC-2, Chris Gary wrote:
>
> How about attributes?
>
>
> [[from_file("shader.vert")]] // Perhaps use the same lookup rules as
> #include
> extern const char src[];    // Size is computed when sizeof() is applied:
> "shader.vert" is loaded and measured. Linker deals with the data later...
>
>
>
Attributes are supposed to be ignorable. Implementations are allowed to
completely ignore them, and this should cause no semantic changes in the
program.

--

---
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_2493_282887931.1424155711798
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 17, 2015 at 3:57:44 AM UTC-2, Chris G=
ary 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"><di=
v>How about attributes?<br><br><div style=3D"background-color:rgb(250,250,2=
50);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-=
wrap:break-word"><code><div><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">[[</span><span style=3D"color:#000">from_file</span><span=
 style=3D"color:#660">(</span><span style=3D"color:#080">"shader.vert"</spa=
n><span style=3D"color:#660">)]]</span><span style=3D"color:#000"> </span><=
span style=3D"color:#800">// Perhaps use the same lookup rules as #include<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#008">exte=
rn</span><span style=3D"color:#000"> </span><span style=3D"color:#008">cons=
t</span><span style=3D"color:#000"> </span><span style=3D"color:#008">char<=
/span><span style=3D"color:#000"> src</span><span style=3D"color:#660">[];<=
/span><span style=3D"color:#000"> &nbsp; &nbsp;</span><span style=3D"color:=
#800">// Size is computed when sizeof() is applied: "shader.vert" is loaded=
 and measured. Linker deals with the data later...</span><span style=3D"col=
or:#000"><br></span><span style=3D"color:#000"><br><br></span></div></code>=
</div></div></div></blockquote><div><br>Attributes are supposed to be ignor=
able. Implementations are allowed to completely ignore them, and this shoul=
d cause no semantic changes in the program.<br></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_2493_282887931.1424155711798--
------=_Part_2492_715929896.1424155711798--

.

------=_Part_256_2134911372.1424156116543
Content-Type: multipart/alternative;
 boundary="----=_Part_257_1298655128.1424156116543"

------=_Part_257_1298655128.1424156116543
Content-Type: text/plain; charset=UTF-8

Yep. So they can also ignore [[dllimport]] (if MS ever does this...) and
other things that would otherwise prevent compilation.

Other attributes that break in terrible ways when ignored include all the
"support" ever implemented for parsing __declspec() (which includes
__declspec(align) and __declspec(property)).

A toolchain that ignores [[from_file("")]] would simply fail to compile it
(can't compute array size, can't link).

It follows that source code expecting this feature would fail to compile,
as expected.


On Monday, February 16, 2015 at 11:48:31 PM UTC-7, Matheus Izvekov wrote:

> Attributes are supposed to be ignorable. Implementations are allowed to
> completely ignore them, and this should cause no semantic changes in the
> program.
>

--

---
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_257_1298655128.1424156116543
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yep. So they can also ignore [[dllimport]] (if MS ever doe=
s this...) and other things that would otherwise prevent compilation.<br><b=
r>Other attributes that break in terrible ways when ignored include all the=
 "support" ever implemented for parsing __declspec() (which includes __decl=
spec(align) and __declspec(property)).<br><br>A toolchain that ignores [[fr=
om_file("")]] would simply fail to compile it (can't compute array size, ca=
n't link).<br><br>It follows that source code expecting this feature would =
fail to compile, as expected.<br><br><br>On Monday, February 16, 2015 at 11=
:48:31 PM UTC-7, Matheus Izvekov wrote:<br><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>Attributes are supposed to be ignorable.=
 Implementations are allowed to completely ignore them, and this should cau=
se no semantic changes in the program.<br></div></div></blockquote></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_257_1298655128.1424156116543--
------=_Part_256_2134911372.1424156116543--

.

On Tuesday 17 February 2015 14:24:03 David Krauss wrote:
> > When compiled to a
> > target with a different endianness, the compiler could be expected to s=
wap
> > things around.
>=20
> My main suggestion is that C++ should provide function that returns a nam=
ed
> resource as a std::istream. Then the programmer chooses between text and
> platform-specific endianness, and the platform build system chooses betwe=
en
> storage in the executable, in a separate file, in a file aggregating
> various resources, etc.

Your suggestion is completely orthogonal to the suggestion from the OP. It=
=20
would be a nice feature to have, but very difficult to implement source fil=
es=20
without #load or without a helper code generator (like Qt's rcc).

> > Which is why I am saying this feature, if adopted, should be restricted=
 to
> > 1- byte entities. That also resolves the question of whether to return =
a
> > character literal or an initializer list: since they are the same, a
> > character literal is easier to understand.
>=20
> I=E2=80=99m not sure what you mean by =E2=80=9Creturn a character literal=
..=E2=80=9D

I was talking about #load. The product of that should be a very long charac=
ter=20
literal, which you can store in an array or manipulate via templates or=20
constexpr functions.

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

--=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 Monday 16 February 2015 22:55:16 Chris Gary wrote:
> Yep. So they can also ignore [[dllimport]] (if MS ever does this...) and
> other things that would otherwise prevent compilation.
>
> Other attributes that break in terrible ways when ignored include all the
> "support" ever implemented for parsing __declspec() (which includes
> __declspec(align) and __declspec(property)).

Those are not C++ standard attributes. As extensions, they are out of scope.

All current C++ standard attributes are ignorable if the compiler does not
implement that feature. That's why alignas is a keyword, not an attribute.

--
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_76_1768489173.1424156989191
Content-Type: multipart/alternative;
 boundary="----=_Part_77_1823856131.1424156989191"

------=_Part_77_1823856131.1424156989191
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 17, 2015 at 4:55:16 AM UTC-2, Chris Gary wrote:
>
> Yep. So they can also ignore [[dllimport]] (if MS ever does this...) and
> other things that would otherwise prevent compilation.
>
> Other attributes that break in terrible ways when ignored include all the
> "support" ever implemented for parsing __declspec() (which includes
> __declspec(align) and __declspec(property)).
>
> A toolchain that ignores [[from_file("")]] would simply fail to compile it
> (can't compute array size, can't link).
>
> It follows that source code expecting this feature would fail to compile,
> as expected.
>

Well, vendor-specific attributes are not bound to this rule anyway, they
can do whatever the vendor pleases.
But core attributes are a different thing altogether.

You are right though that ignoring this would probably only cause the
program to fail to link eventually.

But anyway, this does not mean such a use for attributes would be
acceptable to committee members.

--

---
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_77_1823856131.1424156989191
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 17, 2015 at 4:55:16 AM UTC-2, Chris G=
ary 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">Yep=
.. So they can also ignore [[dllimport]] (if MS ever does this...) and other=
 things that would otherwise prevent compilation.<br><br>Other attributes t=
hat break in terrible ways when ignored include all the "support" ever impl=
emented for parsing __declspec() (which includes __declspec(align) and __de=
clspec(property)).<br><br>A toolchain that ignores [[from_file("")]] would =
simply fail to compile it (can't compute array size, can't link).<br><br>It=
 follows that source code expecting this feature would fail to compile, as =
expected.<br></div></blockquote><div><br>Well, vendor-specific attributes a=
re not bound to this rule anyway, they can do whatever the vendor pleases.<=
br>But core attributes are a different thing altogether.<br><br>You are rig=
ht though that ignoring this would probably only cause the program to fail =
to link eventually.<br><br>But anyway, this does not mean such a use for at=
tributes would be acceptable to committee members.<br></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_77_1823856131.1424156989191--
------=_Part_76_1768489173.1424156989191--

.

------=_Part_135_639599804.1424157549746
Content-Type: multipart/alternative;
 boundary="----=_Part_136_1598252593.1424157549746"

------=_Part_136_1598252593.1424157549746
Content-Type: text/plain; charset=UTF-8



On Monday, February 16, 2015 at 11:24:16 PM UTC-7, David Krauss wrote:
>
>
> *snip*
>

> My main suggestion is that C++ should provide function that returns a
> named resource as a std::istream. Then the programmer chooses between
> text and platform-specific endianness, and the platform build system
> chooses between storage in the executable, in a separate file, in a file
> aggregating various resources, etc.
>
> *snip*
>

I'm not sure if its just me being crazy, though I remember something a
while ago about standardizing localization catalogues in the same manner (I
can't remember exactly what it was). Basically, it followed what you're
suggesting: Let the toolchain decide what a "resource" is and just expose
an istream to its raw data.

This would be the easiest thing to suggest to the committee, I think, as
its just another way to construct a stream. I can immediately see how this
would work on something like android (no more need for JNI just to grab a
bunch of images)...

--

---
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_136_1598252593.1424157549746
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, February 16, 2015 at 11:24:16 PM UTC-7,=
 David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br>*=
snip* <br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div style=3D"word-wrap:break-word"><div><div><br></div><div><div>My main su=
ggestion is that C++ should provide function that returns a named resource =
as a <font face=3D"Courier">std::istream</font>. Then the programmer choose=
s between text and platform-specific endianness, and the platform build sys=
tem chooses between storage in the executable, in a separate file, in a fil=
e aggregating various resources, etc.</div><div><br></div>*snip*</div></div=
></div></blockquote><div><br>I'm not sure if its just me being crazy, thoug=
h I remember something a while ago about standardizing localization catalog=
ues in the same manner (I can't remember exactly what it was). Basically, i=
t followed what you're suggesting: Let the toolchain decide what a "resourc=
e" is and just expose an istream to its raw data.<br><br>This would be the =
easiest thing to suggest to the committee, I think, as its just another way=
 to construct a stream. I can immediately see how this would work on someth=
ing like android (no more need for JNI just to grab a bunch of images)...<b=
r></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_136_1598252593.1424157549746--
------=_Part_135_639599804.1424157549746--

.

------=_Part_127_657589016.1424158425587
Content-Type: multipart/alternative;
 boundary="----=_Part_128_1147744450.1424158425587"

------=_Part_128_1147744450.1424158425587
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 17, 2015 at 12:09:45 AM UTC-7, Thiago Macieira wrote:
>
> On Monday 16 February 2015 22:55:16 Chris Gary wrote:
> *snip*
>
> Those are not C++ standard attributes. As extensions, they are out of
> scope.
>
> All current C++ standard attributes are ignorable if the compiler does not
> implement that feature. That's why alignas is a keyword, not an attribute.
>

AFAIK: Attributes are simply a standardized syntax for whatever the vendor
wanted to do, with the exception of a few reserved names.

Mainly to keep calling convention specifiers and other paraphernalia in a
predictable place.

That is, instead of:

GLint (STDCALL_OR_NIL *glDoSomething)(...);

We would have:

#ifdef _WIN32
#define STDCALL_OR_NIL [[msvc::stdcall]] // whatever this might actually
look like
#else
#define STDCALL_OR_NIL
#endif

STDCALL_OR_NIL
GLint (*glDoSomething)(...);

A minor change, but a definite improvement in usability: Just put all the
random compiler-specific goodies in front of a declaration.

So, I suggested an attribute as a way to implement OP's
very-much-toolchain-specific extension.

--

---
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_128_1147744450.1424158425587
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 17, 2015 at 12:09:45 AM UTC-7, Thiago=
 Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday 16 F=
ebruary 2015 22:55:16 Chris Gary wrote:
<br>*snip*<br>
<br>Those are not C++ standard attributes. As extensions, they are out of s=
cope.
<br>
<br>All current C++ standard attributes are ignorable if the compiler does =
not=20
<br>implement that feature. That's why alignas is a keyword, not an attribu=
te.<br></blockquote><div><br>AFAIK: Attributes are simply a standardized sy=
ntax for whatever the=20
vendor wanted to do, with the exception of a few reserved names.<br><br>Mai=
nly to keep calling convention specifiers and other paraphernalia in a pred=
ictable place.<br><br>That is, instead of:<br><br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">GLint</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">STDCALL_OR_NIL</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span></code>*</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">glDoSomething</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)(...);</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>We wo=
uld have:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">#ifdef _WIN32<br>#define STDCALL_OR_NIL [[msvc::stdcall]] // whatever =
this might actually look like<br>#else<br>#define STDCALL_OR_NIL<br>#endif<=
br><br>STDCALL_OR_NIL<br>GLint (*glDoSomething)(...);<br></span></div></cod=
e></div><br>A minor change, but a definite improvement in usability: Just p=
ut all the random compiler-specific goodies in front of a declaration.<br><=
br>So, I suggested an attribute as a way to implement OP's very-much-toolch=
ain-specific extension.<br></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_128_1147744450.1424158425587--
------=_Part_127_657589016.1424158425587--

.

> On 2015=E2=80=9302=E2=80=9317, at 3:33 PM, Chris Gary <cgary512@gmail.com=
> wrote:
>=20
> AFAIK: Attributes are simply a standardized syntax for whatever the vendo=
r wanted to do, with the exception of a few reserved names.

Now you know this: Attributes are always ignorable.

> Mainly to keep calling convention specifiers and other paraphernalia in a=
 predictable place.

Nope. Although it=E2=80=99s often advisable for vendors to group proprietar=
y keywords together with attributes where possible, they=E2=80=99re not all=
owed to turn keywords into attributes where they convey necessary meaning.

> A minor change, but a definite improvement in usability: Just put all the=
 random compiler-specific goodies in front of a declaration.

Vendors don=E2=80=99t need the standard to tell them where to add extension=
s.

--=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/.

.

--Apple-Mail=_9C954A29-E09E-430F-A26D-1356A4F0619D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9317, at 3:08 PM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> Your suggestion is completely orthogonal to the suggestion from the OP. I=
t=20
> would be a nice feature to have, but very difficult to implement source f=
iles=20
> without #load or without a helper code generator (like Qt's rcc).

Different yes, orthogonal or difficult no.

When the programmer writes something like this:

std::string greeting =3D std::resource( "strings/hello" );

he shouldn=E2=80=99t care, and it should be unspecified, whether the compil=
er ever looks at the file, or the standard library simply opens it at runti=
me.

The standard doesn=E2=80=99t ever mention an =E2=80=9Cexecutable file=E2=80=
=9D or even a =E2=80=9Ccompiler.=E2=80=9D A program simply defines observab=
le behaviors for a computer.

>>> Which is why I am saying this feature, if adopted, should be restricted=
 to
>>> 1- byte entities. That also resolves the question of whether to return =
a
>>> character literal or an initializer list: since they are the same, a
>>> character literal is easier to understand.
>>=20
>> I=E2=80=99m not sure what you mean by =E2=80=9Creturn a character litera=
l.=E2=80=9D
>=20
> I was talking about #load. The product of that should be a very long char=
acter=20
> literal, which you can store in an array or manipulate via templates or=
=20
> constexpr functions.

For text manipulation, we already have raw strings, and #load would just be=
 the same as #include plus raw-string bumpers on the file. That leaves comp=
ile-time binary byte-streams, which are quite a niche to be designing aroun=
d.

--=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/.

--Apple-Mail=_9C954A29-E09E-430F-A26D-1356A4F0619D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9317, at 3:08 PM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macie=
ira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><div class=3D"">Your suggestion is=
 completely orthogonal to the suggestion from the OP. It <br class=3D"">wou=
ld be a nice feature to have, but very difficult to implement source files =
<br class=3D"">without #load or without a helper code generator (like Qt's =
rcc).<br class=3D""></div></div></blockquote><div><br class=3D""></div><div=
>Different yes, orthogonal or difficult no.</div><div><br class=3D""></div>=
<div>When the programmer writes something like this:</div><div><br class=3D=
""></div><div><font face=3D"Courier" class=3D"">std::string greeting =3D st=
d::resource( "strings/hello" );</font></div><div><br class=3D""></div><div>=
he shouldn=E2=80=99t care, and it should be unspecified, whether the compil=
er ever looks at the file, or the standard library simply opens it at runti=
me.</div><div><br class=3D""></div><div>The standard doesn=E2=80=99t ever m=
ention an =E2=80=9Cexecutable file=E2=80=9D or even a =E2=80=9Ccompiler.=E2=
=80=9D A program simply defines observable behaviors for a computer.</div><=
br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div cla=
ss=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" clas=
s=3D"">Which is why I am saying this feature, if adopted, should be restric=
ted to<br class=3D"">1- byte entities. That also resolves the question of w=
hether to return a<br class=3D"">character literal or an initializer list: =
since they are the same, a<br class=3D"">character literal is easier to und=
erstand.<br class=3D""></blockquote><br class=3D"">I=E2=80=99m not sure wha=
t you mean by =E2=80=9Creturn a character literal.=E2=80=9D<br class=3D""><=
/blockquote><br class=3D"">I was talking about #load. The product of that s=
hould be a very long character <br class=3D"">literal, which you can store =
in an array or manipulate via templates or <br class=3D"">constexpr functio=
ns.<br class=3D""></div></div></blockquote><div><br class=3D""></div><div>F=
or text manipulation, we already have raw strings, and <font face=3D"Courie=
r" class=3D"">#load</font>&nbsp;would just be the same as <font face=3D"Cou=
rier" class=3D"">#include</font> plus raw-string bumpers on the file. That =
leaves compile-time binary byte-streams, which are quite a niche to be desi=
gning around.</div></div></body></html>

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

--Apple-Mail=_9C954A29-E09E-430F-A26D-1356A4F0619D--

.

------=_Part_47_1421194837.1424162328861
Content-Type: multipart/alternative;
 boundary="----=_Part_48_1708503525.1424162328862"

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

On Tuesday, February 17, 2015 at 12:52:51 AM UTC-7, David Krauss wrote:

    > Mainly to keep calling convention specifiers and other paraphernalia=
=20
> in a predictable place.
>
>     Nope. Although it=E2=80=99s often advisable for vendors to group prop=
rietary=20
> keywords together with attributes where possible, they=E2=80=99re not all=
owed to=20
> turn keywords into attributes where they convey necessary meaning.
>

Can you clarify that last bit? N2761 seems to suggest them as a replacement=
=20
for all forms of __attribute__ and __declspec (much ado about how they are=
=20
equivalent to GCC's __attribute__). Even mentioning alignment in the "yes,=
=20
do this" bullet list of suggestions.

    > A minor change, but a definite improvement in usability: Just put all=
=20
> the random compiler-specific goodies in front of a declaration.
>
>     Vendors don=E2=80=99t need the standard to tell them where to add ext=
ensions.
>
=20
Well, now they have been given very strong advice indeed! Not that they'll=
=20
listen...

I'm probably just dreaming with that example, though. The calling=20
convention should actually go right next to the pointer, now that I think=
=20
about it.

What I gathered from the (old) draft I have on hand, they could be used for=
=20
things like this:


[[glsl::fragment_source]]
const char *frag_src =3D R"frag(

    main()
    {
        gl_FragColor =3D gl_Color;
    }

)frag";


The purpose of the attribute would be to run the associated string literal=
=20
through a GLSL compiler during translation, allowing any errors raised to=
=20
prevent linking.

Following the guideline bullets: Removing the attribute still leaves a=20
valid raw string literal.

Back to my attribute suggestion:

[[from_file("shader.vert")]]
extern const char str[];

Removing the attribute still leaves a valid declaration. Even though I=20
suggested altering the semantics of the symbol (sizeof() is valid on str=20
where this is supported), this will fail to compile if it is ignored, as=20
desired (the code expects str to point to something, and to be sized=20
statically, as OP desired). This is probably a stark violation of the=20
already vague set of mere suggestions, so I won't pursue it any longer.

Avoiding further digression: I already agree with your suggestion that an=
=20
opaque named-resource-stream would be the most feasible approach to this=20
problem.

It simply isn't reasonable further extend the preprocessor in a way that=20
creates a required coupling with the next stage (needing to 'remember' the=
=20
binding target -- this is what #pragma is for).

Making a preprocessor directive like #load that simply drops "" around its=
=20
contents would require a linefeed after the symbol:

const char *src =3D=20
#load "things.stuff"    // This HAS to be on its own line
;

which looks outright weird.

Other weirdness:

#load_into src "stuff.things"    // Coupling with the next stage: "src" is=
=20
a pp-token here

const char src[];    // what does my decl actually look like?


This could be rephrased as:

#pragma paste_file(src, "stuff.things")

const char src[];    // I still don't know what my decl should look like!

--=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_48_1708503525.1424162328862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 17, 2015 at 12:52:51 AM UTC-7, David =
Krauss wrote:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te">&nbsp;&nbsp;&nbsp; &gt; Mainly to keep calling convention specifiers an=
d other paraphernalia in a predictable place.<br><br>&nbsp;&nbsp;&nbsp; Nop=
e. Although it=E2=80=99s often advisable for vendors to group proprietary k=
eywords together with attributes where possible, they=E2=80=99re not allowe=
d to turn keywords into attributes where they convey necessary meaning.<br>=
</blockquote><br>Can you clarify that last bit? N2761 seems to suggest them=
 as a replacement for all forms of __attribute__ and __declspec (much ado a=
bout how they are equivalent to GCC's __attribute__). Even mentioning align=
ment in the "yes, do this" bullet list of suggestions.<br><br><blockquote><=
blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">&nbsp;&nbsp;&nbsp;=
 &gt; A minor change, but a definite improvement in usability: Just put all=
 the random compiler-specific goodies in front of a declaration.<br><br>&nb=
sp;&nbsp;&nbsp; Vendors don=E2=80=99t need the standard to tell them where =
to add extensions.<br></blockquote></blockquote><div>&nbsp;</div>Well, now =
they have been given very strong advice indeed! Not that they'll listen...<=
br><br>I'm probably just dreaming with that example, though. The calling co=
nvention should actually go right next to the pointer, now that I think abo=
ut it.<br><br>What I gathered from the (old) draft I have on hand, they cou=
ld be used for things like this:<br><br><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">glsl</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">fragment_source</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">]]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">frag_src </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> R</span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">"frag(<br><br>&nbsp; &nbsp; main()<br>&nbsp; &nbsp; {<br>&n=
bsp; &nbsp; &nbsp; &nbsp; gl_FragColor =3D gl_Color;<br>&nbsp; &nbsp; }<br>=
<br>)frag"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n></div></code></div><br><br>The purpose of the attribute would be to run t=
he associated string literal through a GLSL compiler during translation, al=
lowing any errors raised to prevent linking.<br><br>Following the guideline=
 bullets: Removing the attribute still leaves a valid raw string literal.<b=
r><br>Back to my attribute suggestion:<br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">from_file</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">"shader.vert"</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)]]</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">extern</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> str</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[];</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Removi=
ng the attribute still leaves a valid declaration. Even though I suggested =
altering the semantics of the symbol (sizeof() is valid on str where this i=
s supported), this will fail to compile if it is ignored, as desired (the c=
ode expects str to point to something, and to be sized statically, as OP de=
sired). This is probably a stark violation of the already vague set of mere=
 suggestions, so I won't pursue it any longer.<br><br>Avoiding further digr=
ession: I already agree with your suggestion that an opaque named-resource-=
stream would be the most feasible approach to this problem.<br><br>It simpl=
y isn't reasonable further extend the preprocessor in a way that creates a =
required coupling with the next stage (needing to 'remember' the binding ta=
rget -- this is what #pragma is for).<br><br>Making a preprocessor directiv=
e like #load that simply drops "" around its contents would require a linef=
eed after the symbol:<br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">src </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> <br></span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">#load "things.stuff" &nbsp; &nbsp;// This HAS to =
be on its own line</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div></code></div><br>which looks outright weird.<br><br>Other weirdne=
ss:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#=
load_into src "stuff.things" &nbsp; &nbsp;// Coupling with the next stage: =
"src" is a pp-token here</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ch=
ar</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> src</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">[];</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp; &nbsp;</span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">// what does my d=
ecl actually look like?</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span></div></code></div><br><br>This could be rephrased =
as:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#=
pragma</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> pas=
te_file</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">src</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"stuff.things"</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> src</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">[];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &=
nbsp; &nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// I still don't know what my decl should look like!</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><=
br></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_48_1708503525.1424162328862--
------=_Part_47_1421194837.1424162328861--

.

--Apple-Mail=_A3889520-72CA-4872-96DE-3C485E4C135F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9317, at 4:38 PM, Chris Gary <cgary512@gmail.com=
> wrote:
>=20
> Can you clarify that last bit? N2761 seems to suggest them as a replaceme=
nt for all forms of __attribute__ and __declspec (much ado about how they a=
re equivalent to GCC's __attribute__).

That paper predates the decision about ignorability.

> Even mentioning alignment in the "yes, do this" bullet list of suggestion=
s.

C++11 added the alignas specifier which syntactically groups with attribute=
s, but is not an attribute.

> Well, now they have been given very strong advice indeed! Not that they'l=
l listen=E2=80=A6

There has been no official advice about preferring to put extensions with a=
ttributes. I only said it=E2=80=99s =E2=80=9Cadvisable=E2=80=9D because it =
means less new syntax for users to learn.

> I'm probably just dreaming with that example, though. The calling convent=
ion should actually go right next to the pointer, now that I think about it=
..

The standard way of specifying calling conventions is with extern "string" =
linkage specifiers. Vendors have mostly ignored this feature, for whatever =
reason. Personally I=E2=80=99d like to see more of it, though not for somet=
hing like this proposal.

Just for the sake of argument, though, this would be a valid =E2=80=9Cresou=
rce grabber=E2=80=9D extension with no new keywords:

extern "resource" char greeting[] =3D "strings/hello.txt";

> Avoiding further digression: I already agree with your suggestion that an=
 opaque named-resource-stream would be the most feasible approach to this p=
roblem.

Cool! Thanks for bringing up the issue, it=E2=80=99s not something I=E2=80=
=99d have thought of otherwise.

My suggestion almost avoids touching the core language, but I said the stan=
dard function should take a compile-time string. So far such a thing does n=
ot exist, although a couple proposals were presented and received well at t=
he last ISO meeting.

So, my suggestion leads to a choice between proposing a library function th=
at illegally treats a function parameter as a compile-time constant (as in =
my previous example), or proposing that resource names must be marked as co=
mpile-time constants by some suffix which has yet to be standardized, e.g.

std::string greeting =3D std::resource( "strings/hello.txt"cs ); // =E2=80=
=9Ccs=E2=80=9D for =E2=80=9Cconstant string=E2=80=9D

One of the proposals was N4236. I can=E2=80=99t find the other one right no=
w, but they=E2=80=99re functionally equivalent for this purpose.

Compile-time strings have different types from ordinary strings, so std::re=
source could have additional char const * and std::string overloads. That a=
lone might be enough for a proposal, with compile-time functionality left a=
s an extension or subsequent proposal. It might sound trivial, if all it=E2=
=80=99s going to do in practice is prepend a platform-specific prefix to th=
e path, but that=E2=80=99s still a wheel that shouldn=E2=80=99t get reinven=
ted so often.

> #pragma paste_file(src, "stuff.things")
>=20
> const char src[];    // I still don't know what my decl should look like!

#pragma usually signals a platform-specific extension. C has standard pragm=
as but C++ so far does not.

The usual way of adding platform-specific keywords is with a leading double=
 underscore:

const char src[] =3D __paste_file( "stuff.things" );

C likewise standardizes new keywords with a leading underscore and capital =
letter, but C++ so far prefers to add keywords and =E2=80=9Ccontextual keyw=
ords.=E2=80=9D

--=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/.

--Apple-Mail=_A3889520-72CA-4872-96DE-3C485E4C135F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9317, at 4:38 PM, Chris Gary &lt;<a href=3D"mailto:cgary512@gmail.co=
m" class=3D"">cgary512@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-int=
erchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Can you clari=
fy that last bit? N2761 seems to suggest them as a replacement for all form=
s of __attribute__ and __declspec (much ado about how they are equivalent t=
o GCC's __attribute__).</div></div></blockquote><div><br class=3D""></div><=
div><div>That paper predates the decision about ignorability.</div></div><b=
r class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=
=3D"ltr" class=3D"">Even mentioning alignment in the "yes, do this" bullet =
list of suggestions.<br class=3D""></div></div></blockquote><div><br class=
=3D""></div><div>C++11 added the <font face=3D"Courier" class=3D"">alignas<=
/font> specifier which syntactically groups with attributes, but is not an =
attribute.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div cl=
ass=3D""><div dir=3D"ltr" class=3D"">Well, now they have been given very st=
rong advice indeed! Not that they'll listen=E2=80=A6</div></div></blockquot=
e><div><br class=3D""></div><div>There has been no official advice about pr=
eferring to put extensions with attributes. I only said it=E2=80=99s =E2=80=
=9Cadvisable=E2=80=9D because it means less new syntax for users to learn.<=
/div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><d=
iv dir=3D"ltr" class=3D"">I'm probably just dreaming with that example, tho=
ugh. The calling convention should actually go right next to the pointer, n=
ow that I think about it.<br class=3D""></div></div></blockquote><div><br c=
lass=3D""></div><div>The standard way of specifying calling conventions is =
with <font face=3D"Courier" class=3D"">extern "string"</font> linkage speci=
fiers. Vendors have mostly ignored this feature, for whatever reason. Perso=
nally I=E2=80=99d like to see more of it, though not for something like thi=
s proposal.</div><div><br class=3D""></div><div>Just for the sake of argume=
nt, though, this would be a valid =E2=80=9Cresource grabber=E2=80=9D extens=
ion with no new keywords:</div><div><br class=3D""></div><div><font face=3D=
"Courier" class=3D"">extern&nbsp;"resource" char greeting[] =3D "strings/he=
llo.txt"</font><span style=3D"font-family: Courier;" class=3D"">;</span></d=
iv><div><br class=3D""></div><blockquote type=3D"cite" class=3D""><div clas=
s=3D""><div dir=3D"ltr" class=3D"">Avoiding further digression: I already a=
gree with your suggestion that an opaque named-resource-stream would be the=
 most feasible approach to this problem.</div></div></blockquote><div><br c=
lass=3D""></div><div>Cool! Thanks for bringing up the issue, it=E2=80=99s n=
ot something I=E2=80=99d have thought of otherwise.</div><div><br class=3D"=
"></div><div>My suggestion <i class=3D"">almost</i> avoids touching the cor=
e language, but I said the standard function should take a compile-time str=
ing. So far such a thing does not exist, although a couple proposals were p=
resented and received well at the last ISO meeting.</div><div><br class=3D"=
"></div><div>So, my suggestion leads to a choice between proposing a librar=
y function that illegally treats a function parameter as a compile-time con=
stant (as in my previous example), or proposing that resource names must be=
 marked as compile-time constants by some suffix which has yet to be standa=
rdized, e.g.</div><div><br class=3D""></div><div><font face=3D"Courier" cla=
ss=3D"">std::string greeting =3D std::resource( "strings/hello.txt"cs ); //=
 =E2=80=9Ccs=E2=80=9D for =E2=80=9Cconstant string=E2=80=9D</font></div><di=
v><br class=3D""></div><div>One of the proposals was N4236. I can=E2=80=99t=
 find the other one right now, but they=E2=80=99re functionally equivalent =
for this purpose.</div><div><br class=3D""></div><div>Compile-time strings =
have different types from ordinary strings, so <font face=3D"Courier" class=
=3D"">std::resource</font> could have additional <font face=3D"Courier" cla=
ss=3D"">char const *</font> and <font face=3D"Courier" class=3D"">std::stri=
ng</font> overloads. That alone might be enough for a proposal, with compil=
e-time functionality left as an extension or subsequent proposal. It might =
sound trivial, if all it=E2=80=99s going to do in practice is prepend a pla=
tform-specific prefix to the path, but that=E2=80=99s still a wheel that sh=
ouldn=E2=80=99t get reinvented so often.</div><br class=3D""><blockquote ty=
pe=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word;"><code class=3D"prettyprint"><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">#pragma</span> paste_file<span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span>src<span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span> <span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">"stuff.things"</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><br class=3D""><br class=3D""><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span> <span style=3D"=
color: #008;" class=3D"styled-by-prettify">char</span> src<span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">[];</span> &nbsp; &nbsp;<span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// I still don't know what =
my decl should look like!</span></code></div></div></div></blockquote><div>=
<br class=3D""></div><div><font face=3D"Courier" class=3D"">#pragma</font> =
usually signals a platform-specific extension. C has standard pragmas but C=
++ so far does not.</div><div><br class=3D""></div><div>The usual way of ad=
ding platform-specific keywords is with a leading double underscore:</div><=
/div><br class=3D""><div class=3D""><font face=3D"Courier" class=3D"">const=
&nbsp;char&nbsp;src[] =3D __paste_file(&nbsp;"stuff.things" );<br class=3D"=
"></font><br class=3D""></div><div class=3D"">C likewise standardizes new k=
eywords with a leading underscore and capital letter, but C++ so far prefer=
s to add keywords and =E2=80=9Ccontextual keywords.=E2=80=9D</div></body></=
html>

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

--Apple-Mail=_A3889520-72CA-4872-96DE-3C485E4C135F--

.

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

On 2015=E2=80=9302=E2=80=9317, at 5:43 PM, David Krauss <potswa@gmail.com> =
wrote:

My suggestion almost avoids touching the core language, but I said the
standard function should take a compile-time string.


Eh, no, I hadn=E2=80=99t said that. Brain fart, ignore the rest of this.

So far such a thing does not exist, although a couple proposals were
presented and received well at the last ISO meeting.

So, my suggestion leads to a choice between proposing a library function
that illegally treats a function parameter as a compile-time constant (as
in my previous example), or proposing that resource names must be marked as
compile-time constants by some suffix which has yet to be standardized, e.g=
..

std::string greeting =3D std::resource( "strings/hello.txt"cs ); // =E2=80=
=9Ccs=E2=80=9D for
=E2=80=9Cconstant string=E2=80=9D

One of the proposals was N4236. I can=E2=80=99t find the other one right no=
w, but
they=E2=80=99re functionally equivalent for this purpose.

Compile-time strings have different types from ordinary strings, so
std::resource could have additional char const * and std::string overloads.
That alone might be enough for a proposal, with compile-time functionality
left as an extension or subsequent proposal. It might sound trivial, if all
it=E2=80=99s going to do in practice is prepend a platform-specific prefix =
to the
path, but that=E2=80=99s still a wheel that shouldn=E2=80=99t get reinvente=
d so often.

--=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/.

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

<div dir=3D"ltr"><br style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><blockquote>On 2=
015=E2=80=9302=E2=80=9317, at 5:43 PM, David Krauss &lt;<a href=3D"mailto:p=
otswa@gmail.com">potswa@gmail.com</a>&gt; wrote:<br><br>My suggestion almos=
t avoids touching the core language, but I said the standard function shoul=
d take a compile-time string.<br></blockquote><br>Eh, no, I hadn=E2=80=99t =
said that. Brain fart, ignore the rest of this.<br><br><blockquote>So far s=
uch a thing does not exist, although a couple proposals were presented and =
received well at the last ISO meeting.<br><br>So, my suggestion leads to a =
choice between proposing a library function that illegally treats a functio=
n parameter as a compile-time constant (as in my previous example), or prop=
osing that resource names must be marked as compile-time constants by some =
suffix which has yet to be standardized, e.g.<br><br>std::string greeting =
=3D std::resource( &quot;strings/hello.txt&quot;cs ); // =E2=80=9Ccs=E2=80=
=9D for =E2=80=9Cconstant string=E2=80=9D<br><br>One of the proposals was N=
4236. I can=E2=80=99t find the other one right now, but they=E2=80=99re fun=
ctionally equivalent for this purpose.<br><br>Compile-time strings have dif=
ferent types from ordinary strings, so std::resource could have additional =
char const * and std::string overloads. That alone might be enough for a pr=
oposal, with compile-time functionality left as an extension or subsequent =
proposal. It might sound trivial, if all it=E2=80=99s going to do in practi=
ce is prepend a platform-specific prefix to the path, but that=E2=80=99s st=
ill a wheel that shouldn=E2=80=99t get reinvented so often.<br></blockquote=
><br></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 />

--bcaec51b1c19041943050f48a3b2--

.

On 2015-02-17 02:52, David Krauss wrote:
>> On 2015=E2=80=9302=E2=80=9317, at 3:33 PM, Chris Gary wrote:
>>
>> AFAIK: Attributes are simply a standardized syntax for whatever the vend=
or wanted to do, with the exception of a few reserved names.
>=20
> Now you know this: Attributes are always ignorable.

Yes... and no. A compiler that ignores attributes can be conforming.
Things may fall apart if you are relying on non-standard attributes to
be parsed by the compiler that provides the same, and it suddenly
changes its mind, but you're already in non-standard territory there.
Code relying on arbitrary compilers to support non-standard attributes
is broken.

IOW, it's reasonable to write code that relies on the compiler
supporting an attribute where said code knows that the compiler supports
said attribute. It would not be reasonable in such case for the compiler
to say that it supports the attribute (if the attribute introduces a
semantic change) and then ignore it. It's also reasonable for a compiler
to ignore all attributes (provided that it doesn't claim to do otherwise).

--=20
Matthew

--=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 2015-02-16 23:38, Chris Gary wrote:
> Matthew Woehlke wrote:
>> Okay, I'm confused... above you say "it is a tremendously bad idea to
>> bake any resource into a binary", but here you are suggesting exactly
>> that?
>
> Its still a bad idea (have to distribute a patch for a change of icon).
> Just pointing out that its been done.

And how *else* are you going to distribute a change of icon? You're
going to have to distribute *something* - preferably an automated
something - for *any* sort of change. At that point, I don't see it
making much difference if the changed file(s) are data or binaries. (On
most Linux systems, it makes exactly zero difference, as the "patch" is
a complete rebuild of the package. I'm not entirely up to speed on OS/X
bundles, but I think they're in the same boat.)

If you're in some domain where that isn't the case... then don't use the
feature :-). As Thiago said, I don't see that one corner case where this
doesn't work should prevent accepting it when it would be useful for
many other cases.

>> Who said anything about semantic checking?
>
> I meant to say "syntax checking", though "semantic" still applies here
> (e.g. CUDA extensions). More important than "it just compiling" is "it not
> compiling when it shouldn't work."

I meant that literally. *Now* it's been brought up, but when I wrote
that, I don't recall that anyone had suggested this feature do anything
but "paste" file contents; no syntax / semantic checking involved.

That could be nice, but it's not necessary, and certainly not worth
derailing the proposal.

--
Matthew

--

---
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 2015-02-16 19:46, Thiago Macieira wrote:
> On Monday 16 February 2015 17:10:50 Matthew Woehlke wrote:
>>> is onto something. It allows you to specify the format (uint8_t vs char)
>>> and linkage of the variable. If it expands to `{0x50, 0x51, ... }` then
>>> this can also work with std::vector, and std::string, although I can't see
>>> a way to make it work with std::array because that requires the size in a
>>> template argument.
>>
>> Hmm... that's a really great idea, but I'm not sure if it's ideal. The
>> trouble is that a string literal decomposes into a char*, while an
>> initializer_list (effectively what you're suggesting) I'm pretty sure
>> does not. In particular, I could imagine this being limiting with
>> libraries that can't construct a string type from an initializer_list.
>> That said, I think both have their uses; maybe the syntax should allow
>> specifying which is wanted? (And if not... I think I agree that the
>> initializer_list is more generally useful in modern code.)
>
> Two questions:
>
> a) why would you store the array into anything except a static const array or
> a template type that is equivalent to that? If the template type takes an
> array by reference, it doesn't matter if the string was "foo" or
> {'f', 'o', 'o', 0}

Again, an initializer list does not implicitly convert to a char const*.
I can't pass it to anything that expects a char const*; I have to assign
it to a variable first. I may not want to do that; I can readily
conceive instances where storing it in a variable is just unneeded
overhead, i.e. I could readily just pass it directly to some function.

That's my main concern with the list format.

> b) why would the underlying element type be anything other than char?

Why not uchar? Different API's expect different representations of "raw
memory bytes". (Sure, you can reinterpret_cast, but why not avoid that
if we can?)

Why you'd ever *want* to use, say, int, I don't know, but I'd be
surprised if the compiler choked on it if the operation is defined as
producing a list of char literals.

As I see it, the most important reasons to let the user decide is to
allow direct use in constructors/factories (e.g. std::string,
std::make_array), to allow specifying storage (e.g. static, const...
there's no reason this couldn't be used to initialize a non-const
array), and so forth. This is also why the list format should be
supported; class constructors are more likely to accept an
initializer_list than to have a templated constructor to accept a
known-size character array literal.

--
Matthew

--

---
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 2015-02-16 20:29, David Krauss wrote:
>> On 2015=E2=80=9302=E2=80=9317, at 8:46 AM, Thiago Macieira wrote:
>>
>> a) why would you store the array into anything except a static const arr=
ay or=20
>> a template type that is equivalent to that? If the template type takes a=
n=20
>> array by reference, it doesn't matter if the string was "foo" or=20
>> {'f', 'o', 'o', 0}
>=20
> For large resources, it=E2=80=99s seldom practical to load them all befor=
e=20
> main starts. Although virtual memory and shared libraries can help=20
> alleviate the pain, the tried-and-true solution is to load resource=20
> files at runtime. Embedded systems with little RAM and no VM might
> have no choice.

....and, as Thiago said, such systems aren't going to use this feature.
Or any other resource system that embeds resources into the binary, for
that matter.

I'm curious how many such platforms exist that would even have large
resources used? (Do iOS / Android / etc. not have VM? I would have
thought they do...)

On platforms with VM and read only data segments, I would expect the
resource data would be in a RO segment (same as the rest of the code)
that would have essentially zero overhead versus an external file on
disk. (Possibly less, unless you're mmap'ing the file, as I believe
fread() would *always* be reading into RAM, whereas RO data may not, or
at least can be swapped out without using the swap file, or if there
*is* no swap file.)

> Serializing initializer lists is an interesting thought, but I think=20
> that problem is orthogonal to the means of storage. You can=E2=80=99t
> serialize a std::initializer_list of non-serializable objects.

We're only talking about [u]char here, though.

--=20
Matthew

--=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 February 2015 11:31:13 Matthew Woehlke wrote:
> I'm curious how many such platforms exist that would even have large
> resources used? (Do iOS / Android / etc. not have VM? I would have
> thought they do...)
>
> On platforms with VM and read only data segments, I would expect the
> resource data would be in a RO segment (same as the rest of the code)
> that would have essentially zero overhead versus an external file on
> disk. (Possibly less, unless you're mmap'ing the file, as I believe
> fread() would *always* be reading into RAM, whereas RO data may not, or
> at least can be swapped out without using the swap file, or if there
> *is* no swap file.)

On an architecture that supports paging, it's easy for the OS to provide VM
support and memory-mapped files. That's a key target for embedded binary
content: it's loaded as read-only, always-pure, shareable pages. That means
the content can also be demand-loaded and discarded when there's memory
pressure.

The problem is when you're trying to write software for systems without paging
support. That means the entire binary would need to be loaded into main RAM
and stay there, including all resources, whether the are needed or not. That
doesn't sound to me like a very good use of resources. Those kind of systems
are more of a target for the solution that David proposed: manually load on
demand.

You asked whether they are common -- they still are and are gaining again in
relevance, as we move to the "Internet of Things" world when your toaster and
light switches want to connect to a network.

There's a sub-category of the no-paging systems: the execute-in-place systems
(see https://en.wikipedia.org/wiki/Execute_in_place). I don't have enough
experience with those to provide meaningful conclusions, though.

--
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 February 2015 11:31:19 Matthew Woehlke wrote:
> Why not uchar? Different API's expect different representations of "raw
> memory bytes". (Sure, you can reinterpret_cast, but why not avoid that
> if we can?)

static const unsigned char foo[] = "Hello";

--
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 2015-02-17 15:03, Thiago Macieira wrote:
> The problem is when you're trying to write software for systems without paging
> support. That means the entire binary would need to be loaded into main RAM
> and stay there, including all resources, whether the are needed or not. That
> doesn't sound to me like a very good use of resources. Those kind of systems
> are more of a target for the solution that David proposed: manually load on
> demand.

Right. This isn't a feature you'd use in such cases. (Nor e.g. Qt's
system which AFAIK is roughly equivalent.)

> You asked whether they are common -- they still are and are gaining again in
> relevance, as we move to the "Internet of Things" world when your toaster and
> light switches want to connect to a network.

On the other hand, I am curious what sorts of "resources" you are even
using on such systems? Somehow I'm not seeing much in the way of
graphics on your light switch :-).

--
Matthew

--

---
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 2015-02-17 15:04, Thiago Macieira wrote:
> On Tuesday 17 February 2015 11:31:19 Matthew Woehlke wrote:
>> Why not uchar? Different API's expect different representations of "raw
>> memory bytes". (Sure, you can reinterpret_cast, but why not avoid that
>> if we can?)
>
> static const unsigned char foo[] = "Hello";

Sorry, I may have misread the question. The "pasted content" or whatever
you want to call it should be such that it can be stored as an array of
'char'. (Or 'uchar', but as you note, that seems to Just Work. Likewise
'int', etc.)

I may be missing the context that caused you to ask the question in the
first place...

--
Matthew

--

---
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 February 2015 15:19:50 Matthew Woehlke wrote:
> On 2015-02-17 15:03, Thiago Macieira wrote:
> > The problem is when you're trying to write software for systems without
> > paging support. That means the entire binary would need to be loaded into
> > main RAM and stay there, including all resources, whether the are needed
> > or not. That doesn't sound to me like a very good use of resources. Those
> > kind of systems are more of a target for the solution that David
> > proposed: manually load on demand.
>
> Right. This isn't a feature you'd use in such cases. (Nor e.g. Qt's
> system which AFAIK is roughly equivalent.)

QResource also supports reading a resource directory directly from a file,
instead of something registered inside the binary image (see
QResource::registerResource).

But David's description is more similar to QFileSelector.

> > You asked whether they are common -- they still are and are gaining again
> > in relevance, as we move to the "Internet of Things" world when your
> > toaster and light switches want to connect to a network.
>
> On the other hand, I am curious what sorts of "resources" you are even
> using on such systems? Somehow I'm not seeing much in the way of
> graphics on your light switch :-).

Many of those may contain small web servers for configuration and management,
which means they may have icons they wish to send to you. Another scenario I
can think of is the transfer of prepared responses over the communication
channel. If nothing else, they probably have multiple preconfigured encryption
keys that may not be required all the time.

The size of the RAM on such systems that I'm hearing about would scare even my
DOS-using 1992 self...

http://download.intel.com/newsroom/kits/ces/2015/pdfs/Intel_CURIE_Module_Factsheet.pdf
- 384 kB Flash, 80 kB SRAM. At 80 kB, a 2048-bit RSA key + certificate would
occupy around 1% of your memory, so you may not want to keep it past the
initial TLS handshake.

--
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 Tue, Feb 17, 2015 at 05:43:58PM +0800, David Krauss wrote:
>=20
> > On 2015=E2=80=9302=E2=80=9317, at 4:38 PM, Chris Gary <cgary512@gmail.c=
om> wrote:
> >=20
> > Can you clarify that last bit? N2761 seems to suggest them as a replace=
ment for all forms of __attribute__ and __declspec (much ado about how they=
 are equivalent to GCC's __attribute__).
>=20
> That paper predates the decision about ignorability.
>=20
> > Even mentioning alignment in the "yes, do this" bullet list of suggesti=
ons.
>=20
> C++11 added the alignas specifier which syntactically groups with attribu=
tes, but is not an attribute.
>=20
> > Well, now they have been given very strong advice indeed! Not that they=
'll listen=E2=80=A6
>=20
> There has been no official advice about preferring to put extensions with=
 attributes. I only said it=E2=80=99s =E2=80=9Cadvisable=E2=80=9D because i=
t means less new syntax for users to learn.
>=20
> > I'm probably just dreaming with that example, though. The calling conve=
ntion should actually go right next to the pointer, now that I think about =
it.
>=20
> The standard way of specifying calling conventions is with extern "string=
" linkage specifiers. Vendors have mostly ignored this feature, for whateve=
r reason. Personally I=E2=80=99d like to see more of it, though not for som=
ething like this proposal.
>=20
> Just for the sake of argument, though, this would be a valid =E2=80=9Cres=
ource grabber=E2=80=9D extension with no new keywords:
>=20
> extern "resource" char greeting[] =3D "strings/hello.txt";

This form drops the original forms ability to be used not only in character
arrays but also in argument lists, template argument lists and as an
expression. (ok, the expression form ain't very useful)

Consider:

char greeting[] =3D {
#load "strings/hello.txt"
}

otherGreeting<
#load "strings/hello.txt"
> bar;

thirdGreeting(
#load "strings/hello.txt"
);

and finally there is

fourthGreeting,
#load "strings/hello.txt"
; /* The rather useless case... */

--=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 Wednesday 18 February 2015 00:17:15 Magnus Fromreide wrote:
> char greeting[] = {
> #load "strings/hello.txt"
> }
>
> otherGreeting<
> #load "strings/hello.txt"
>
> > bar;
>
> thirdGreeting(
> #load "strings/hello.txt"
> );
>
> and finally there is

You can replace those with a load into a constexpr char variable and pass that
to the template or function call.

We're not talking about loading a file and interpreting it as C++ source code.
We have #include for that already.
--
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_2174_1418128488.1424278366534
Content-Type: multipart/alternative;
 boundary="----=_Part_2175_1711983410.1424278366534"

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

On Tuesday, February 17, 2015 at 11:30:10 PM UTC-8, Thiago Macieira wrote:
>
> On Wednesday 18 February 2015 00:17:15 Magnus Fromreide wrote:=20
> > char greeting[] =3D {=20
> > #load "strings/hello.txt"=20
> > }=20
> >=20
> > otherGreeting<=20
> > #load "strings/hello.txt"=20
> >=20
> > > bar;=20
> >=20
> > thirdGreeting(=20
> > #load "strings/hello.txt"=20
> > );=20
> >=20
> > and finally there is=20
>
> You can replace those with a load into a constexpr char variable and pass=
=20
> that=20
> to the template or function call.=20
>

Not with the same semantics, though.
otherGreeting<"abc">
has a very different meaning from
otherGreeting<'a', 'b', 'c'>
..
=20

> We're not talking about loading a file and interpreting it as C++ source=
=20
> code.=20
> We have #include for that already.
>

Magnus's suggestion was not to load a file and interpret it as source code;=
=20
it was to load a file and "interpret" it as a comma-separated sequence of=
=20
character literals. For example,

int a[]=3D{
#load __FILE__
};

when preprocessed would produce

int a[] =3D {
   'i', 'n', 't', ' ', 'a', '[', ']', '=3D', '{', '\n', '#', 'l', 'o', 'a',=
=20
'd', ' ', '_', '_', 'F', 'I', 'L', 'E', '_', '_', '\n', '}', ';', '\n'
};

I think Magnus's is a reasonable suggestion... except for the fact that it=
=20
already exists, in the form of the standard utility program xxd. I don't=20
see any reason to merge the functionalities of xxd and cc into a single=20
program, when they work perfectly fine as separate programs. (Or, if=20
someone in this thread claims that they *don't* work perfectly fine, I'd=20
like to see that claim made explicitly, and then backed up with at least a=
=20
bit of ancedotal evidence.)

=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_2175_1711983410.1424278366534
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 17, 2015 at 11:30:10 PM UTC-8, Thiago=
 Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wednesday 1=
8 February 2015 00:17:15 Magnus Fromreide wrote:
<br>&gt; char greeting[] =3D {
<br>&gt; #load "strings/hello.txt"
<br>&gt; }
<br>&gt;=20
<br>&gt; otherGreeting&lt;
<br>&gt; #load "strings/hello.txt"
<br>&gt;=20
<br>&gt; &gt; bar;
<br>&gt;=20
<br>&gt; thirdGreeting(
<br>&gt; #load "strings/hello.txt"
<br>&gt; );
<br>&gt;=20
<br>&gt; and finally there is
<br>
<br>You can replace those with a load into a constexpr char variable and pa=
ss that=20
<br>to the template or function call.
<br></blockquote><div><br></div><div>Not with the same semantics, though.</=
div><div>otherGreeting&lt;"abc"&gt;</div><div>has a very different meaning =
from</div><div>otherGreeting&lt;'a', 'b', 'c'&gt;</div><div>.</div><div>&nb=
sp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">We're not talking=
 about loading a file and interpreting it as C++ source code.=20
<br>We have #include for that already.<br></blockquote><div><br></div><div>=
Magnus's suggestion was not to load a file and interpret it as source code;=
 it was to load a file and "interpret" it as a comma-separated sequence of =
character literals. For example,</div><div><br></div><div>int a[]=3D{</div>=
<div>#load __FILE__</div><div>};</div><div><br></div><div>when preprocessed=
 would produce</div><div><br></div><div>int a[] =3D {</div><div>&nbsp; &nbs=
p;'i', 'n', 't', ' ', 'a', '[', ']', '=3D', '{', '\n', '#', 'l', 'o', 'a', =
'd', ' ', '_', '_', 'F', 'I', 'L', 'E', '_', '_', '\n', '}', ';', '\n'</div=
><div>};</div><div><br></div><div>I think Magnus's is a reasonable suggesti=
on... except for the fact that it already exists, in the form of the standa=
rd utility program <font face=3D"courier new, monospace">xxd</font>. I don'=
t see any reason to merge the functionalities of <font face=3D"courier new,=
 monospace">xxd</font> and <font face=3D"courier new, monospace">cc</font>&=
nbsp;into a single program, when they work perfectly fine as separate progr=
ams. (Or, if someone in this thread claims that they <b>don't</b> work perf=
ectly fine, I'd like to see that claim made explicitly, and then backed up =
with at least a bit of ancedotal evidence.)</div><div><br></div><div>=E2=80=
=93Arthur</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_2175_1711983410.1424278366534--
------=_Part_2174_1418128488.1424278366534--

.

On 2015-02-18 11:52, Arthur O'Dwyer wrote:
> I think Magnus's is a reasonable suggestion... except for the fact that it
> already exists, in the form of the standard utility program xxd.

  $ rpm -qf /usr/bin/xxd
  vim-common-7.4.475-2.fc20.x86_64

Really? So in order to use resources in a C++ program I should be
required to install vim? (I'm sure this will surprise no one, and that
emacs fans won't be in the slightest annoyed...)

  C:\Program Files (x86)>xxd
  'xxd' is not recognized as an internal or external command,
  operable program or batch file.

Oh, look, *it's not portable* either. (That was in my MSVC shell, btw.)

I have to disagree with you; this is sufficiently useful to justify
being part of the compiler, which would make it portable and usable with
no build-system dependencies.

--
Matthew

--

---
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 Wednesday 18 February 2015 08:52:46 Arthur O'Dwyer wrote:
> > You can replace those with a load into a constexpr char variable and pass
> > that
> > to the template or function call.
>
> Not with the same semantics, though.
> otherGreeting<"abc">
> has a very different meaning from
> otherGreeting<'a', 'b', 'c'>

But it should have the same meaning as
 otherGreeting<{'a', 'b', 'c'}>

which is what it seems to me it should be. The #load should produce one token,
not multiple comma-separated ones.

We don't want this:

 static const uchar data[] = 'a', 'b', 'c';

> > We're not talking about loading a file and interpreting it as C++ source
> > code.
> > We have #include for that already.
>
> Magnus's suggestion was not to load a file and interpret it as source code;
> it was to load a file and "interpret" it as a comma-separated sequence of
> character literals. For example,
>
> int a[]={
> #load __FILE__
> };
>
> when preprocessed would produce
>
> int a[] = {
>    'i', 'n', 't', ' ', 'a', '[', ']', '=', '{', '\n', '#', 'l', 'o', 'a',
> 'd', ' ', '_', '_', 'F', 'I', 'L', 'E', '_', '_', '\n', '}', ';', '\n'
> };

That's an interesting suggestion, but that's not how I had read it. I was
expecting that the { } would be unnecessary. Hence my reply.

> I think Magnus's is a reasonable suggestion... except for the fact that it
> already exists, in the form of the standard utility program xxd. I don't
> see any reason to merge the functionalities of xxd and cc into a single
> program, when they work perfectly fine as separate programs. (Or, if
> someone in this thread claims that they *don't* work perfectly fine, I'd
> like to see that claim made explicitly, and then backed up with at least a
> bit of ancedotal evidence.)

I also don't think there's anything wrong with code generators.

--
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_4173_386745129.1424283084135
Content-Type: multipart/alternative;
 boundary="----=_Part_4174_1739867281.1424283084135"

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


If I have a table in Mysql

CREATE TABLE my_table( cod int(10), nm varchar(30) )

Can I somehow parse the ".frm"

WEIRED_PARSE_MACRO(#load "..\..\..\var\mysql_data\my_table.frm");

and get a structure ?=20

struct my_table{
   int cod;
   std::string nm;
};

Thanks



Em ter=C3=A7a-feira, 17 de fevereiro de 2015 21:17:20 UTC-2, Magnus Fromrei=
de=20
escreveu:
>
> On Tue, Feb 17, 2015 at 05:43:58PM +0800, David Krauss wrote:=20
> >=20
> > > On 2015=E2=80=9302=E2=80=9317, at 4:38 PM, Chris Gary <cgar...@gmail.=
com <javascript:>>=20
> wrote:=20
> > >=20
> > > Can you clarify that last bit? N2761 seems to suggest them as a=20
> replacement for all forms of __attribute__ and __declspec (much ado about=
=20
> how they are equivalent to GCC's __attribute__).=20
> >=20
> > That paper predates the decision about ignorability.=20
> >=20
> > > Even mentioning alignment in the "yes, do this" bullet list of=20
> suggestions.=20
> >=20
> > C++11 added the alignas specifier which syntactically groups with=20
> attributes, but is not an attribute.=20
> >=20
> > > Well, now they have been given very strong advice indeed! Not that=20
> they'll listen=E2=80=A6=20
> >=20
> > There has been no official advice about preferring to put extensions=20
> with attributes. I only said it=E2=80=99s =E2=80=9Cadvisable=E2=80=9D bec=
ause it means less new=20
> syntax for users to learn.=20
> >=20
> > > I'm probably just dreaming with that example, though. The calling=20
> convention should actually go right next to the pointer, now that I think=
=20
> about it.=20
> >=20
> > The standard way of specifying calling conventions is with extern=20
> "string" linkage specifiers. Vendors have mostly ignored this feature, fo=
r=20
> whatever reason. Personally I=E2=80=99d like to see more of it, though no=
t for=20
> something like this proposal.=20
> >=20
> > Just for the sake of argument, though, this would be a valid =E2=80=9Cr=
esource=20
> grabber=E2=80=9D extension with no new keywords:=20
> >=20
> > extern "resource" char greeting[] =3D "strings/hello.txt";=20
>
> This form drops the original forms ability to be used not only in=20
> character=20
> arrays but also in argument lists, template argument lists and as an=20
> expression. (ok, the expression form ain't very useful)=20
>
> Consider:=20
>
> char greeting[] =3D {=20
> #load "strings/hello.txt"=20
> }=20
>
> otherGreeting<=20
> #load "strings/hello.txt"=20
> > bar;=20
>
> thirdGreeting(=20
> #load "strings/hello.txt"=20
> );=20
>
> and finally there is=20
>
> fourthGreeting,=20
> #load "strings/hello.txt"=20
> ; /* The rather useless case... */=20
>

--=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_4174_1739867281.1424283084135
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>If I have a table in Mysql</div><div><=
br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187=
, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#6=
60066"><span style=3D"color: #000;" class=3D"styled-by-prettify">CREATE TAB=
LE my_table</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> cod </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">10</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> nm varchar</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">30</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span></font></div></code></div><br>Can I somehow parse the ".frm"<br></div=
><div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid =
rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, =
250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">WEIRED_PARSE_MACRO</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">#load "..\..\..\var\mysql_da=
ta\my_table.frm");</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span></div></code></div><br></div><div>and get a structure ?&=
nbsp;<br></div><div><br></div><div><div class=3D"prettyprint" style=3D"bord=
er: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: =
rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><font color=3D"#660066"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> my_table</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> co=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> nm</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">};</span></font></div></code></div><div><b=
r></div>Thanks<br><br></div><br><br>Em ter=C3=A7a-feira, 17 de fevereiro de=
 2015 21:17:20 UTC-2, Magnus Fromreide  escreveu:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">On Tue, Feb 17, 2015 at 05:43:58PM +0800, David Krauss w=
rote:
<br>&gt;=20
<br>&gt; &gt; On 2015=E2=80=9302=E2=80=9317, at 4:38 PM, Chris Gary &lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CTFFDssrLfM=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;">cgar...@gmail.com</a>&gt=
; wrote:
<br>&gt; &gt;=20
<br>&gt; &gt; Can you clarify that last bit? N2761 seems to suggest them as=
 a replacement for all forms of __attribute__ and __declspec (much ado abou=
t how they are equivalent to GCC's __attribute__).
<br>&gt;=20
<br>&gt; That paper predates the decision about ignorability.
<br>&gt;=20
<br>&gt; &gt; Even mentioning alignment in the "yes, do this" bullet list o=
f suggestions.
<br>&gt;=20
<br>&gt; C++11 added the alignas specifier which syntactically groups with =
attributes, but is not an attribute.
<br>&gt;=20
<br>&gt; &gt; Well, now they have been given very strong advice indeed! Not=
 that they'll listen=E2=80=A6
<br>&gt;=20
<br>&gt; There has been no official advice about preferring to put extensio=
ns with attributes. I only said it=E2=80=99s =E2=80=9Cadvisable=E2=80=9D be=
cause it means less new syntax for users to learn.
<br>&gt;=20
<br>&gt; &gt; I'm probably just dreaming with that example, though. The cal=
ling convention should actually go right next to the pointer, now that I th=
ink about it.
<br>&gt;=20
<br>&gt; The standard way of specifying calling conventions is with extern =
"string" linkage specifiers. Vendors have mostly ignored this feature, for =
whatever reason. Personally I=E2=80=99d like to see more of it, though not =
for something like this proposal.
<br>&gt;=20
<br>&gt; Just for the sake of argument, though, this would be a valid =E2=
=80=9Cresource grabber=E2=80=9D extension with no new keywords:
<br>&gt;=20
<br>&gt; extern "resource" char greeting[] =3D "strings/hello.txt";
<br>
<br>This form drops the original forms ability to be used not only in chara=
cter
<br>arrays but also in argument lists, template argument lists and as an
<br>expression. (ok, the expression form ain't very useful)
<br>
<br>Consider:
<br>
<br>char greeting[] =3D {
<br>#load "strings/hello.txt"
<br>}
<br>
<br>otherGreeting&lt;
<br>#load "strings/hello.txt"
<br>&gt; bar;
<br>
<br>thirdGreeting(
<br>#load "strings/hello.txt"
<br>);
<br>
<br>and finally there is
<br>
<br>fourthGreeting,
<br>#load "strings/hello.txt"
<br>; /* The rather useless case... */
<br></blockquote></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_4174_1739867281.1424283084135--
------=_Part_4173_386745129.1424283084135--

.

On 2015-02-18 13:11, Cleiton Santoia wrote:
> If I have a table in Mysql
>
> CREATE TABLE my_table( cod int(10), nm varchar(30) )
>
> Can I somehow parse the ".frm"
>
> WEIRED_PARSE_MACRO(#load "..\..\..\var\mysql_data\my_table.frm");
>
> and get a structure ?
>
> struct my_table{
>    int cod;
>    std::string nm;
> };

....only if WEIRD_PARSE_MACRO can go from {'C','R','E' /*...*/
'3','0',')',' ',')',0} to that. That sounds rather more like a job for a
specialized code generator.

--
Matthew

--

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

.

If I understand the way this thread is going, it would seem to me
better to extend #include to load from a pipe.

On 2/18/15, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> On 2015-02-18 13:11, Cleiton Santoia wrote:
>> If I have a table in Mysql
>>
>> CREATE TABLE my_table( cod int(10), nm varchar(30) )
>>
>> Can I somehow parse the ".frm"
>>
>> WEIRED_PARSE_MACRO(#load "..\..\..\var\mysql_data\my_table.frm");
>>
>> and get a structure ?
>>
>> struct my_table{
>>    int cod;
>>    std::string nm;
>> };
>
> ...only if WEIRD_PARSE_MACRO can go from {'C','R','E' /*...*/
> '3','0',')',' ',')',0} to that. That sounds rather more like a job for a
> specialized code generator.
>
> --
> Matthew
>
> --
>
> ---
> 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/.
>

--

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

.

e.g.

#include "tokenise foo.txt|"

where the '|' signifies the pipe.

On 2/18/15, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> If I understand the way this thread is going, it would seem to me
> better to extend #include to load from a pipe.
>
> On 2/18/15, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> On 2015-02-18 13:11, Cleiton Santoia wrote:
>>> If I have a table in Mysql
>>>
>>> CREATE TABLE my_table( cod int(10), nm varchar(30) )
>>>
>>> Can I somehow parse the ".frm"
>>>
>>> WEIRED_PARSE_MACRO(#load "..\..\..\var\mysql_data\my_table.frm");
>>>
>>> and get a structure ?
>>>
>>> struct my_table{
>>>    int cod;
>>>    std::string nm;
>>> };
>>
>> ...only if WEIRD_PARSE_MACRO can go from {'C','R','E' /*...*/
>> '3','0',')',' ',')',0} to that. That sounds rather more like a job for a
>> specialized code generator.
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> 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/.
>>
>

--

---
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_1835_829338914.1424286161141
Content-Type: multipart/alternative;
 boundary="----=_Part_1836_791595904.1424286161147"

------=_Part_1836_791595904.1424286161147
Content-Type: text/plain; charset=UTF-8

As the author of incbin (I also go by graphitemaster) I feel like this
discussion has been mostly derailed about the purposes of what the original
proposer, Tim suggested.
The proposal was not about incorporating a resource system into C++, nor
was it about suggesting a library component to incorporate into the
standard library. This is
purely a proposal about introducing a method (in the language) to include
binary assets as-is into the program.

Assemblers have had this capability long before C even existed. In fact,
the first original language before C, mainly B, had always supported means
to specify storage for
the final kludge as simple statement-directives in B. The first C, which
was just B with backwards compound operators and weird function
declarations rid with it because
the preconstruct (The B compiler used to bootstrap C.) had inline assembler
that could include binary data. We lost it when C++ more or less picked up
where C had left off,
when it should've at least looked at where C came from itself. That's
enough history.

It irritates me that since the beginning of computing in general, ways to
incorporate binary data has always existed without the need to use external
preprocessing tools or
build steps which are non-portable and quite frankly ridiculous. If the
committees view has been "If it can be done with a build tool, do that
first before adding something to the language",
then raw string literals is not really following those rules. I'm not, and
never have been a fan of introducing build complexity to a project just to
achieve something.
Judging both by how popular incbin itself has become and how much
bike-shedding has been going on here, I can within reasonable
interpretation justify that there is use for something
like this in the language.

For added build step complexity it can be done reasonably well, sure. But
people like myself compile for a variety of platforms, on a variety of
compilers, cross compilation
included, and the one thing I've come to accept is to avoid doing any sort
of external processing as a build step because there is just too many
permutations for targets that
can go wrong at any time, impossible for any one individual to test and
quite frankly, ridiculousness. It's always better to utilize the compiler,
since it's the only thing that
has to be consistent due to standardization.

I don't care what the syntax is, but I can assure you that the language
shouldn't interpret the data as anything but a raw sequence of bytes. There
should be no endianess conversion,
alignment, or other nonsensical things done to the data. The md5sum of a
dump of the data should compare equal to that of the md5sum of the included
data once it's 'embedded' in
the kludge.

--

---
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_1836_791595904.1424286161147
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As the author of incbin (I also go by graphitemaster) I fe=
el like this discussion has been mostly derailed about the purposes of what=
 the original proposer, Tim suggested.<br>The proposal was not about incorp=
orating a resource system into C++, nor was it about suggesting a library c=
omponent to incorporate into the standard library. This is<br>purely a prop=
osal about introducing a method (in the language) to include binary assets =
as-is into the program.<br><br>Assemblers have had this capability long bef=
ore C even existed. In fact, the first original language before C, mainly B=
, had always supported means to specify storage for<br>the final kludge as =
simple statement-directives in B. The first C, which was just B with backwa=
rds compound operators and weird function declarations rid with it because<=
br>the preconstruct (The B compiler used to bootstrap C.) had inline assemb=
ler that could include binary data. We lost it when C++ more or less picked=
 up where C had left off,<br>when it should've at least looked at where C c=
ame from itself. That's enough history.<br><br>It irritates me that since t=
he beginning of computing in general, ways to incorporate binary data has a=
lways existed without the need to use external preprocessing tools or<br>bu=
ild steps which are non-portable and quite frankly ridiculous. If the commi=
ttees view has been "If it can be done with a build tool, do that first bef=
ore adding something to the language",<br>then raw string literals is not r=
eally following those rules. I'm not, and never have been a fan of introduc=
ing build complexity to a project just to achieve something.<br>Judging bot=
h by how popular incbin itself has become and how much bike-shedding has be=
en going on here, I can within reasonable interpretation justify that there=
 is use for something<br>like this in the language.<br><br>For added build =
step complexity it can be done reasonably well, sure. But people like mysel=
f compile for a variety of platforms, on a variety of compilers, cross comp=
ilation<br>included, and the one thing I've come to accept is to avoid doin=
g any sort of external processing as a build step because there is just too=
 many permutations for targets that<br>can go wrong at any time, impossible=
 for any one individual to test and quite frankly, ridiculousness. It's alw=
ays better to utilize the compiler, since it's the only thing that<br>has t=
o be consistent due to standardization.<br><br>I don't care what the syntax=
 is, but I can assure you that the language shouldn't interpret the data as=
 anything but a raw sequence of bytes. There should be no endianess convers=
ion,<br>alignment, or other nonsensical things done to the data. The md5sum=
 of a dump of the data should compare equal to that of the md5sum of the in=
cluded data once it's 'embedded' in<br>the kludge.<br></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_1836_791595904.1424286161147--
------=_Part_1835_829338914.1424286161141--

.

On 2015-02-18 13:55, Douglas Boffey wrote:
> If I understand the way this thread is going, it would seem to me
> better to extend #include to load from a pipe.

No. That *would* be way out of context of the original suggestion. It's
also unnecessary; code generation is clearly the job of build systems.

Let me reiterate: the suggestion *is not about (complex) code
generation*. It is about inserting the contents of a file as code-level
data (i.e. string literals or initializer lists, as opposed to code,
which is what #include does).

(Another way to look at it is that it is about inserting file contents
such that the raw contents wind up on CODE/RODATA without further
translation, as opposed to being processed as code. That is, *less*
translation. Not more. Please don't derail the thread.)

--
Matthew

--

---
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 2015-02-18 14:02, Dale Weiler wrote:
> The proposal was not about incorporating a resource system into C++,
> nor was it about suggesting a library component to incorporate into
> the standard library. This is purely a proposal about introducing a
> method (in the language) to include binary assets as-is into the
> program.

....the obvious purpose of which is to implement a resource system :-).
True, it is not proposing any form of advanced resource management. Nor
does it need to; that's what identifiers are for.

That said, I think it's reasonable to consider that this is a major
motivating use case and that this won't entirely solve that problem.

Still, I agree with the sentiment that we shouldn't get bogged down in
adding functionality to something that should be inherently quite
simple. That's why I'm not in favor of any of the counter-proposals that
wandered off in this direction.

> For added build step complexity it can be done reasonably well, sure.
> But people like myself compile for a variety of platforms, on a
> variety of compilers, cross compilation included, and the one thing
> I've come to accept is to avoid doing any sort of external processing
> as a build step because there is just too many permutations for
> targets that can go wrong at any time, impossible for any one
> individual to test and quite frankly, ridiculousness. It's always
> better to utilize the compiler, since it's the only thing that has to
> be consistent due to standardization.

Hear, hear!

> I don't care what the syntax is, but I can assure you that the language
> shouldn't interpret the data as anything but a raw sequence of bytes. There
> should be no endianess conversion,

I wouldn't *oppose* endian conversion as such, but it's a nice-to-have.
The no-conversion flavor on the other hand is bare minimum functionality.

> alignment,

Alignment can and should be handled as part of the storage declaration,
i.e. it is orthogonal to the "paste operator" (or whatever you want to
call it). So... yes, the paste operator itself shouldn't know/care.

--
Matthew

--

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

.

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

On Wed, Feb 18, 2015 at 11:19 AM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2015-02-18 13:55, Douglas Boffey wrote:
>> If I understand the way this thread is going, it would seem to me
>> better to extend #include to load from a pipe.

FWIW, that seems reasonable to me (Perl does something like that with its
equivalent of fopen) =E2=80=94 *EXCEPT* for the massive security problem. C=
ompiling
a C++ program mustn't result in executing arbitrary shell commands!

    #include `rm -rf *`  // ha ha

> No. That *would* be way out of context of the original suggestion. It's
> also unnecessary; code generation is clearly the job of build systems.
>
> Let me reiterate: the suggestion *is not about (complex) code
> generation*. It is about inserting the contents of a file as code-level
> data (i.e. string literals or initializer lists, as opposed to code,
> which is what #include does).

In other words, the suggestion is about taking a binary file, preprocessing
it in such a way as to insert singlequote-comma-singlequote between each
pair of bytes (with appropriate escaping), and then textually including the
result of that preprocessing into the C++ source file currently under
translation.

....Or, how else would you define "inserting the contents of a file [as]
string literals or initializer lists"?...

So, we need a mechanism for textually including the result of a
preprocessing step. Well, C++ already has a mechanism for textual
inclusion: namely, #include. So all that's missing is a way to #include the
output of some preprocessing step. Obviously you can do it via a temporary
file, on any build system in the world; but if you for some reason *MUST*
have everything built into cc, then an obvious answer would indeed be to
have #include be able to accept the result of a pipe.

=E2=80=93Arthur

P.S.: Windows versions of xxd are available here, according to Google:
http://superuser.com/questions/497953/convert-hex-dump-of-file-to-binarypro=
gram-file-on-windows
http://www.weihenstephan.de/~syring/win32/UnxUtilsDist.html

--=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/.

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

<div dir=3D"ltr">On Wed, Feb 18, 2015 at 11:19 AM, Matthew Woehlke &lt;<a h=
ref=3D"mailto:mw_triad@users.sourceforge.net">mw_triad@users.sourceforge.ne=
t</a>&gt; wrote:<br>&gt; On 2015-02-18 13:55, Douglas Boffey wrote:<br>&gt;=
&gt; If I understand the way this thread is going, it would seem to me<br>&=
gt;&gt; better to extend #include to load from a pipe.<br><br>FWIW, that se=
ems reasonable to me (Perl does something like that with its equivalent of =
<font face=3D"monospace, monospace">fopen</font>) =E2=80=94 <i>EXCEPT</i> f=
or the massive security problem. Compiling a C++ program mustn&#39;t result=
 in executing arbitrary shell commands!<div><div><br></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 #include `rm -rf *` =C2=A0// ha ha<=
br></font><br>&gt; No. That *would* be way out of context of the original s=
uggestion. It&#39;s<br>&gt; also unnecessary; code generation is clearly th=
e job of build systems.<br>&gt;<br>&gt; Let me reiterate: the suggestion *i=
s not about (complex) code<br>&gt; generation*. It is about inserting the c=
ontents of a file as code-level<br>&gt; data (i.e. string literals or initi=
alizer lists, as opposed to code,<br>&gt; which is what #include does).<br>=
<br>In other words, the suggestion is about taking a binary file, preproces=
sing it in such a way as to insert singlequote-comma-singlequote between ea=
ch pair of bytes (with appropriate escaping), and then textually including =
the result of that preprocessing into the C++ source file currently under t=
ranslation.<br><br>...Or, how else would you define &quot;inserting the con=
tents of a file [as] string literals or initializer lists&quot;?...<div><br=
></div><div>So, we need a mechanism for textually including the result of a=
 preprocessing step. Well, C++ already has a mechanism for textual inclusio=
n: namely, <font face=3D"monospace, monospace">#include</font>. So all that=
&#39;s missing is a way to <font face=3D"monospace, monospace">#include</fo=
nt> the output of some preprocessing step. Obviously you can do it via a te=
mporary file, on any build system in the world; but if you for some reason =
*MUST* have everything built into=C2=A0<font face=3D"monospace, monospace">=
cc</font>, then an obvious answer would indeed be to have <font face=3D"mon=
ospace, monospace">#include</font> be able to accept the result of a pipe.<=
/div><div><br></div><div>=E2=80=93Arthur<br><br>P.S.: Windows versions of <=
font face=3D"monospace, monospace">xxd</font> are available here, according=
 to Google:<br><a href=3D"http://superuser.com/questions/497953/convert-hex=
-dump-of-file-to-binaryprogram-file-on-windows">http://superuser.com/questi=
ons/497953/convert-hex-dump-of-file-to-binaryprogram-file-on-windows</a><br=
><a href=3D"http://www.weihenstephan.de/~syring/win32/UnxUtilsDist.html">ht=
tp://www.weihenstephan.de/~syring/win32/UnxUtilsDist.html</a><br></div></di=
v></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 />

--f46d04426c8ed49bef050f6236d0--

.

On 2015-02-18 14:56, Arthur O'Dwyer wrote:
>> On 2015-02-18 13:55, Douglas Boffey wrote:
>>> If I understand the way this thread is going, it would seem to me
>>> better to extend #include to load from a pipe.
>=20
> FWIW, that seems reasonable to me (Perl does something like that with its
> equivalent of fopen) =E2=80=94 *EXCEPT* for the massive security problem.=
 Compiling
> a C++ program mustn't result in executing arbitrary shell commands!
>=20
>     #include `rm -rf *`  // ha ha

....but *running* said program is okay? What about every build manager in
existence; are you going to fix those also?

  # Makefile
  all: foo evulz

  foo: foo.cpp
    $CC -o foo foo.cpp

  evulz:
    rm -rf ~/

> On Wed, Feb 18, 2015 at 11:19 AM, Matthew Woehlke wrote:
>> No. That *would* be way out of context of the original suggestion. It's
>> also unnecessary; code generation is clearly the job of build systems.
>>
>> Let me reiterate: the suggestion *is not about (complex) code
>> generation*. It is about inserting the contents of a file as code-level
>> data (i.e. string literals or initializer lists, as opposed to code,
>> which is what #include does).
>=20
> In other words, the suggestion is about taking a binary file, preprocessi=
ng
> it in such a way as to insert singlequote-comma-singlequote between each
> pair of bytes (with appropriate escaping), and then textually including t=
he
> result of that preprocessing into the C++ source file currently under
> translation.

Actually, the behavior should probably be specified "as if". However,
that sort of misses the point. The point is, if I have some sequence of
bytes in a file, and I __load that file, the *exact same sequence of
bytes* should end up in the compiled object.

(For that matter, if we don't try to specify the feature in terms of the
preprocessor, it's conceivable that the compiler could automagically
decide to use an initializer_list or string literal (i.e. char const*)
depending on the context. Whether or not it's a good idea to actually
specify that behavior, however...)

> So, we need a mechanism for textually including the result of a
> preprocessing step.

Under the "as if" rule, the compiler could simply copy the data to an
appropriate segment and insert the proper reference to the same. This
would also be much more efficient...

> So all that's missing is a way to #include the
> output of some preprocessing step.

That's not missing at all; that's the job of the build manager.

What we *are* missing is a *portable* way to go from binary data on disk
to binary data in code. xxd *is not* that way. IMO this is a
sufficiently common problem that esoteric tools should not be required
to solve it. It should be built into the compiler. (Also IMO, process
invocation should *absolutely not* be built into the compiler.)

--=20
Matthew

--=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_4450_1915557126.1424291674368
Content-Type: multipart/alternative;
 boundary="----=_Part_4451_1841264505.1424291674368"

------=_Part_4451_1841264505.1424291674368
Content-Type: text/plain; charset=UTF-8



> What we *are* missing is a *portable* way to go from binary data on disk
> to binary data in code. xxd *is not* that way. IMO this is a
> sufficiently common problem that esoteric tools should not be required
> to solve it. It should be built into the compiler. (Also IMO, process
> invocation should *absolutely not* be built into the compiler.)
>

This is precisely the point Tim and I have been trying to make. It's not a
matter of how it can be done with existing
tools and added build complexity, it's about giving the job of including
the binary data to the compiler so it can construct
the appropriate external references and let the linker deal with the rest
(which is the most efficient way of doing this.)

I still think the people who are arguing against this don't understand the
actual problem at all because they're confusing
what it means to "include" binary data into the application. The people who
advocate that #include is sufficent are not
fully understanding that it isn't. The closest you can do is something like
this (which is non-standard preprocessing usage.)

#define STR(X) #X

const char data[] = STR(
  #include "file.txt"
);

The standard does not allow preprocessing directives to be used in the
context of a macro argument list, GCC, Clang accept
this as an extension however (Linux kernel depends on this iirc.). The
obvious problem with this is when the contents of file.txt
itself contains preprocessing directive, it fails short. GLSL shader for
instance have C preprocessing tokens as part of its language
so one cannot do this

// frag.glsl
#version 330
uniform vec4 outColor;
void main() { outColor = vec4(1, 0, 0, 1); }

// C++ code
#define STR(X) #
const char data[] = STR(
  #include "frag.glsl"
);

This will complain because of the "#version 330"


--

---
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_4451_1841264505.1424291674368
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">What we *=
are* missing is a *portable* way to go from binary data on disk
<br>to binary data in code. xxd *is not* that way. IMO this is a
<br>sufficiently common problem that esoteric tools should not be required
<br>to solve it. It should be built into the compiler. (Also IMO, process
<br>invocation should *absolutely not* be built into the compiler.)
<br></blockquote><div><br>This is precisely the point Tim and I have been t=
rying to make. It's not a matter of how it can be done with existing<br>too=
ls and added build complexity, it's about giving the job of including the b=
inary data to the compiler so it can construct<br>the appropriate external =
references and let the linker deal with the rest (which is the most efficie=
nt way of doing this.)<br><br>I still think the people who are arguing agai=
nst this don't understand the actual problem at all because they're confusi=
ng<br>what it means to "include" binary data into the application. The peop=
le who advocate that #include is sufficent are not<br>fully understanding t=
hat it isn't. The closest you can do is something like this (which is non-s=
tandard preprocessing usage.)<br><br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">#define</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> STR</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">X</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">#X</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> data</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 STR</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">#include</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">"file.txt"</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>The s=
tandard does not allow preprocessing directives to be used in the context o=
f a macro argument list, GCC, Clang accept<br>this as an extension however =
(Linux kernel depends on this iirc.). The obvious problem with this is when=
 the contents of file.txt<br>itself contains preprocessing directive, it fa=
ils short. GLSL shader for instance have C preprocessing tokens as part of =
its language<br>so one cannot do this<br><code><br></code><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><code><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// frag.glsl</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">#version 330</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>uniform vec4 outColor=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> outColor </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> vec4</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">// C++ code</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">#define</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> STR</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">X</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">#</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">char</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> data</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">[]</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> STR</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">#include</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #080;" class=3D"styled-by-prettify">"frag.glsl"</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span></code></div></code></div><br>This=
 will complain because of the "#version 330"<br><br><br></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_4451_1841264505.1424291674368--
------=_Part_4450_1915557126.1424291674368--

.

On 02/18/2015 09:23 PM, Matthew Woehlke wrote:

> What we *are* missing is a *portable* way to go from binary data on disk
> to binary data in code. xxd *is not* that way. IMO this is a

If you do not mind run-time conversion on some platforms, then something
like the buffer types of Boost.Endian [1] would be a good way to handle
portability of this data.

[1] https://boostorg.github.io/endian/buffers.html

--

---
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_797_580490738.1424294704760
Content-Type: multipart/alternative;
 boundary="----=_Part_798_289625245.1424294704760"

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

This could be possible if someone decides to work out my idea of=20
meta-programming. It's about 'constexpr' functions and 'variables' which=20
will be evaluated at compile-time. I think this is a very important concept=
=20
- because many new modern apps waste a lot - I mean really a lot of=20
performance doing static initialization at run-time and it's all left to=20
compiler optimizing them out - but he can't handle it all. This post proves=
=20
this - today if you want to load a resource file - you should always use=20
external library calls (like 'fstream') which will surely be instanced at=
=20
run-time and thus waste performance. The solution of using the preprocessor=
=20
shows weak in this example as it have no idea what a structure is. That's=
=20
why editing language primitives using the language itself will be a lot=20
more useful.

I meant what I say because the today definition of 'constexpr' doesn't=20
guarantee anything about compile-time execution unless in certain context=
=20
and even then we can't load files at compile-time and manipulate types.

I could work out the idea myself but have a lot more important things to do=
=20
unfortunately.

=D1=81=D1=80=D1=8F=D0=B4=D0=B0, 18 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=B0=D1=
=80=D0=B8 2015 =D0=B3., 20:11:24 UTC+2, Cleiton Santoia =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:
>
>
> If I have a table in Mysql
>
> CREATE TABLE my_table( cod int(10), nm varchar(30) )
>
> Can I somehow parse the ".frm"
>
> WEIRED_PARSE_MACRO(#load "..\..\..\var\mysql_data\my_table.frm");
>
> and get a structure ?=20
>
> struct my_table{
>    int cod;
>    std::string nm;
> };
>
> Thanks
>
>
>
> Em ter=C3=A7a-feira, 17 de fevereiro de 2015 21:17:20 UTC-2, Magnus Fromr=
eide=20
> escreveu:
>>
>> On Tue, Feb 17, 2015 at 05:43:58PM +0800, David Krauss wrote:=20
>> >=20
>> > > On 2015=E2=80=9302=E2=80=9317, at 4:38 PM, Chris Gary <cgar...@gmail=
..com> wrote:=20
>> > >=20
>> > > Can you clarify that last bit? N2761 seems to suggest them as a=20
>> replacement for all forms of __attribute__ and __declspec (much ado abou=
t=20
>> how they are equivalent to GCC's __attribute__).=20
>> >=20
>> > That paper predates the decision about ignorability.=20
>> >=20
>> > > Even mentioning alignment in the "yes, do this" bullet list of=20
>> suggestions.=20
>> >=20
>> > C++11 added the alignas specifier which syntactically groups with=20
>> attributes, but is not an attribute.=20
>> >=20
>> > > Well, now they have been given very strong advice indeed! Not that=
=20
>> they'll listen=E2=80=A6=20
>> >=20
>> > There has been no official advice about preferring to put extensions=
=20
>> with attributes. I only said it=E2=80=99s =E2=80=9Cadvisable=E2=80=9D be=
cause it means less new=20
>> syntax for users to learn.=20
>> >=20
>> > > I'm probably just dreaming with that example, though. The calling=20
>> convention should actually go right next to the pointer, now that I thin=
k=20
>> about it.=20
>> >=20
>> > The standard way of specifying calling conventions is with extern=20
>> "string" linkage specifiers. Vendors have mostly ignored this feature, f=
or=20
>> whatever reason. Personally I=E2=80=99d like to see more of it, though n=
ot for=20
>> something like this proposal.=20
>> >=20
>> > Just for the sake of argument, though, this would be a valid =E2=80=9C=
resource=20
>> grabber=E2=80=9D extension with no new keywords:=20
>> >=20
>> > extern "resource" char greeting[] =3D "strings/hello.txt";=20
>>
>> This form drops the original forms ability to be used not only in=20
>> character=20
>> arrays but also in argument lists, template argument lists and as an=20
>> expression. (ok, the expression form ain't very useful)=20
>>
>> Consider:=20
>>
>> char greeting[] =3D {=20
>> #load "strings/hello.txt"=20
>> }=20
>>
>> otherGreeting<=20
>> #load "strings/hello.txt"=20
>> > bar;=20
>>
>> thirdGreeting(=20
>> #load "strings/hello.txt"=20
>> );=20
>>
>> and finally there is=20
>>
>> fourthGreeting,=20
>> #load "strings/hello.txt"=20
>> ; /* The rather useless case... */=20
>>
>

--=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_798_289625245.1424294704760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This could be possible if someone decides to work out my i=
dea of meta-programming. It's about 'constexpr' functions and 'variables' w=
hich will be evaluated at compile-time. I think this is a very important co=
ncept - because many new modern apps waste a lot - I mean really a lot of p=
erformance doing static initialization at run-time and it's all left to com=
piler optimizing them out - but he can't handle it all. This post proves th=
is - today if you want to load a resource file - you should always use exte=
rnal library calls (like 'fstream') which will surely be instanced at run-t=
ime and thus waste performance. The solution of using the preprocessor show=
s weak in this example as it have no idea what a structure is. That's why e=
diting language primitives using the language itself will be a lot more use=
ful.<div><br></div><div>I meant what I say because the today definition of =
'constexpr' doesn't guarantee anything about compile-time execution unless =
in certain context and even then we can't load files at compile-time and ma=
nipulate types.</div><div><br></div><div>I could work out the idea myself b=
ut have a lot more important things to do unfortunately.<br><br>=D1=81=D1=
=80=D1=8F=D0=B4=D0=B0, 18 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=B0=D1=80=D0=B8 =
2015 =D0=B3., 20:11:24 UTC+2, Cleiton Santoia =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0:<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"><di=
v><br></div><div>If I have a table in Mysql</div><div><br></div><div><div s=
tyle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-c=
olor:rgb(250,250,250)"><code><div><font color=3D"#660066"><span style=3D"co=
lor:#000">CREATE TABLE my_table</span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#000"> cod </span><span style=3D"color:#008">int</span><=
span style=3D"color:#660">(</span><span style=3D"color:#066">10</span><span=
 style=3D"color:#660">),</span><span style=3D"color:#000"> nm varchar</span=
><span style=3D"color:#660">(</span><span style=3D"color:#066">30</span><sp=
an style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">)</span></font></div></code></div><br>Can I somehow pars=
e the ".frm"<br></div><div><br></div><div><div style=3D"border:1px solid rg=
b(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><cod=
e><div><span style=3D"color:#000">WEIRED_PARSE_MACRO</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#800">#load "..\..\..\var\mysql_dat=
a\my_<wbr>table.frm");</span><span style=3D"color:#000"><br></span></div></=
code></div><br></div><div>and get a structure ?&nbsp;<br></div><div><br></d=
iv><div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-wor=
d;background-color:rgb(250,250,250)"><code><div><font color=3D"#660066"><sp=
an style=3D"color:#008">struct</span><span style=3D"color:#000"> my_table</=
span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbs=
p; &nbsp;</span><span style=3D"color:#008">int</span><span style=3D"color:#=
000"> cod</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"><br>&nbsp; &nbsp;std</span><span style=3D"color:#660">::</span><span sty=
le=3D"color:#008">string</span><span style=3D"color:#000"> nm</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">};</span></font></div></code></div><div><br></div>Thanks<=
br><br></div><br><br>Em ter=C3=A7a-feira, 17 de fevereiro de 2015 21:17:20 =
UTC-2, Magnus Fromreide  escreveu:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Tue, Feb 17, 2015 at 05:43:58PM +0800, David Krauss wrote:
<br>&gt;=20
<br>&gt; &gt; On 2015=E2=80=9302=E2=80=9317, at 4:38 PM, Chris Gary &lt;<a =
rel=3D"nofollow">cgar...@gmail.com</a>&gt; wrote:
<br>&gt; &gt;=20
<br>&gt; &gt; Can you clarify that last bit? N2761 seems to suggest them as=
 a replacement for all forms of __attribute__ and __declspec (much ado abou=
t how they are equivalent to GCC's __attribute__).
<br>&gt;=20
<br>&gt; That paper predates the decision about ignorability.
<br>&gt;=20
<br>&gt; &gt; Even mentioning alignment in the "yes, do this" bullet list o=
f suggestions.
<br>&gt;=20
<br>&gt; C++11 added the alignas specifier which syntactically groups with =
attributes, but is not an attribute.
<br>&gt;=20
<br>&gt; &gt; Well, now they have been given very strong advice indeed! Not=
 that they'll listen=E2=80=A6
<br>&gt;=20
<br>&gt; There has been no official advice about preferring to put extensio=
ns with attributes. I only said it=E2=80=99s =E2=80=9Cadvisable=E2=80=9D be=
cause it means less new syntax for users to learn.
<br>&gt;=20
<br>&gt; &gt; I'm probably just dreaming with that example, though. The cal=
ling convention should actually go right next to the pointer, now that I th=
ink about it.
<br>&gt;=20
<br>&gt; The standard way of specifying calling conventions is with extern =
"string" linkage specifiers. Vendors have mostly ignored this feature, for =
whatever reason. Personally I=E2=80=99d like to see more of it, though not =
for something like this proposal.
<br>&gt;=20
<br>&gt; Just for the sake of argument, though, this would be a valid =E2=
=80=9Cresource grabber=E2=80=9D extension with no new keywords:
<br>&gt;=20
<br>&gt; extern "resource" char greeting[] =3D "strings/hello.txt";
<br>
<br>This form drops the original forms ability to be used not only in chara=
cter
<br>arrays but also in argument lists, template argument lists and as an
<br>expression. (ok, the expression form ain't very useful)
<br>
<br>Consider:
<br>
<br>char greeting[] =3D {
<br>#load "strings/hello.txt"
<br>}
<br>
<br>otherGreeting&lt;
<br>#load "strings/hello.txt"
<br>&gt; bar;
<br>
<br>thirdGreeting(
<br>#load "strings/hello.txt"
<br>);
<br>
<br>and finally there is
<br>
<br>fourthGreeting,
<br>#load "strings/hello.txt"
<br>; /* The rather useless case... */
<br></blockquote></div></blockquote></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_798_289625245.1424294704760--
------=_Part_797_580490738.1424294704760--

.

On Wednesday 18 February 2015 18:55:23 Douglas Boffey wrote:
> If I understand the way this thread is going, it would seem to me
> better to extend #include to load from a pipe.

Pipes are not a cross-platform concept. There are common OSes that don't
support pipes.

In fact, processes aren't a cross-platform concept. It's highly unlikely that
you're running a compiler in an OS that runs everything single-process, but
hey the Java compiler is actually a library in the standard Java distribution,
so why not?

--
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 Wednesday 18 February 2015 11:02:41 Dale Weiler wrote:
> I don't care what the syntax is, but I can assure you that the language
> shouldn't interpret the data as anything but a raw sequence of bytes. There
> should be no endianess conversion,

What should the compiler do if the input narrow charset is not the same as the
execution narrow charset? Worse yet, what if the size of the byte is different?
(cross-compiling to a platform where CHAR_BIT is different from the host
platform where the file is stored)

--
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_2561_353713574.1424345706176
Content-Type: multipart/alternative;
 boundary="----=_Part_2562_629303322.1424345706176"

------=_Part_2562_629303322.1424345706176
Content-Type: text/plain; charset=UTF-8


On Wednesday, February 18, 2015 at 10:44:59 PM UTC-7, Thiago Macieira wrote:
>
> On Wednesday 18 February 2015 11:02:41 Dale Weiler wrote:
> > I don't care what the syntax is, but I can assure you that the language
> > shouldn't interpret the data as anything but a raw sequence of bytes.
> There
> > should be no endianess conversion,
>
> What should the compiler do if the input narrow charset is not the same as
> the
> execution narrow charset? Worse yet, what if the size of the byte is
> different?
> (cross-compiling to a platform where CHAR_BIT is different from the host
> platform where the file is stored)
>

I think the idea is: Whatever it expands to is treated symbolically (like
pasting text).

It could just expand to a sequence of char literals that get inserted into
an AST as though they were parsed from source.

Dealing with differences in character sets is the programmer's
responsibility; no different than (not) using ASCII above 127 in a source
file.

Let the "text" version of the utility assume that its consuming a blob of
nothing but source characters and surrounding them with single quotes.

The "binary" version would expand to a sequence of untyped hex literals
(like 0xAA, 0xBB, 0xCC, 0xDD).

--

---
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_2562_629303322.1424345706176
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, February 18, 2015 at 10:44:59 PM UTC-7, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wedne=
sday 18 February 2015 11:02:41 Dale Weiler wrote:
<br>&gt; I don't care what the syntax is, but I can assure you that the lan=
guage=20
<br>&gt; shouldn't interpret the data as anything but a raw sequence of byt=
es. There=20
<br>&gt; should be no endianess conversion,
<br>
<br>What should the compiler do if the input narrow charset is not the same=
 as the=20
<br>execution narrow charset? Worse yet, what if the size of the byte is di=
fferent?=20
<br>(cross-compiling to a platform where CHAR_BIT is different from the hos=
t=20
<br>platform where the file is stored)
<br></blockquote><div><br>I think the idea is: Whatever it expands to is tr=
eated symbolically (like pasting text).<br><br>It could just expand to a se=
quence of char literals that get inserted into an AST as though they were p=
arsed from source.<br><br>Dealing with differences in character sets is the=
 programmer's responsibility; no different than (not) using ASCII above 127=
 in a source file.<br><br>Let the "text" version of the utility assume that=
 its consuming a blob of nothing but source characters and surrounding them=
 with single quotes.<br><br>The "binary" version would expand to a sequence=
 of untyped hex literals (like 0xAA, 0xBB, 0xCC, 0xDD).<br></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_2562_629303322.1424345706176--
------=_Part_2561_353713574.1424345706176--

.

------=_Part_1118_928604388.1424345929838
Content-Type: multipart/alternative;
 boundary="----=_Part_1119_1290286367.1424345929838"

------=_Part_1119_1290286367.1424345929838
Content-Type: text/plain; charset=UTF-8

Clarifying further:

Either version could allow specification of an element type (e.g. 'char',
'short', 'int', etc...), and however large that is determines the
granularity at which 'char'-sized elements from the source document are
consumed.

In the "wider-than-char" case of the "text" version, I suppose the result
could be a sequence of UCN literals.

--

---
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_1119_1290286367.1424345929838
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Clarifying further:<br><br>Either version could allow spec=
ification of an element type (e.g. 'char', 'short', 'int', etc...), and how=
ever large that is determines the granularity at which 'char'-sized element=
s from the source document are consumed.<br><br>In the "wider-than-char" ca=
se of the "text" version, I suppose the result could be a sequence of UCN l=
iterals.<br></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_1119_1290286367.1424345929838--
------=_Part_1118_928604388.1424345929838--

.

------=_Part_1566_1099125467.1424360455698
Content-Type: multipart/alternative;
 boundary="----=_Part_1567_347392375.1424360455699"

------=_Part_1567_347392375.1424360455699
Content-Type: text/plain; charset=UTF-8

On Thursday, February 19, 2015 at 4:38:50 AM UTC-7, Chris Gary wrote:
>
> Clarifying further:
>
> Either version could allow specification of an element type (e.g. 'char',
> 'short', 'int', etc...), and however large that is determines the
> granularity at which 'char'-sized elements from the source document are
> consumed.
>
> In the "wider-than-char" case of the "text" version, I suppose the result
> could be a sequence of UCN literals.
>

Have some examples!

const auto src = static_text<char>("shader.vert");

const auto wtxt = static_text<wchar_t>("dialogue.msg");

const auto datBlob = static_data<uint8_t>("blob.dat");

const auto datBigBlob = static_data<uint32_t>("big_blob.dat");



--

---
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_1567_347392375.1424360455699
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 19, 2015 at 4:38:50 AM UTC-7, Chris =
Gary 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">Cl=
arifying further:<br><br>Either version could allow specification of an ele=
ment type (e.g. 'char', 'short', 'int', etc...), and however large that is =
determines the granularity at which 'char'-sized elements from the source d=
ocument are consumed.<br><br>In the "wider-than-char" case of the "text" ve=
rsion, I suppose the result could be a sequence of UCN literals.<br></div><=
/blockquote><div><br>Have some examples!<br><br><div class=3D"prettyprint" =
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, =
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> src </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> static_text</span><span style=3D"color: #080;" class=3D"styled-by-pr=
ettify">&lt;char&gt;</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
>"shader.vert"</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">const<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> wtxt </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> static_text</span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">&lt;wchar_t&gt;</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"dialogue.msg"</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> datBlob </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> static_data</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">&lt;uint8_t&gt;</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify=
">"blob.dat"</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> datBigBlob </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> static_data</span><span style=3D=
"color: #080;" class=3D"styled-by-prettify">&lt;uint32_t&gt;</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #080;" class=3D"styled-by-prettify">"big_blob.dat"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>&n=
bsp;<br></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_1567_347392375.1424360455699--
------=_Part_1566_1099125467.1424360455698--

.

On 2015-02-19 00:44, Thiago Macieira wrote:
> On Wednesday 18 February 2015 11:02:41 Dale Weiler wrote:
>> I don't care what the syntax is, but I can assure you that the language=
=20
>> shouldn't interpret the data as anything but a raw sequence of bytes. Th=
ere=20
>> should be no endianess conversion,
>=20
> What should the compiler do if the input narrow charset is not the same a=
s the=20
> execution narrow charset?

Nothing; the user must perform an appropriate conversion at run-time,
same as if they had read the data from a separate file at run-time. The
low level objective is to transport *binary* data (which works for text
also in the trivial case).

We *could* support text conversion, but as previously stated, that's
'nice to have'; we should get the simple case sorted first. (Anyway,
considering how well text conversion is (not) supported in the standard
library anyway, I imagine this would be a bit of a stretch...)

That said... a mode to convert \r\n =E2=86=92 \n might not be out of line.

> Worse yet, what if the size of the byte is different?=20
> (cross-compiling to a platform where CHAR_BIT is different from the
> host platform where the file is stored)

For this case, I agree with Chris; the 'as if' rule would have to become
'in fact'. (And likely you must store the data in a sufficiently wide
data type.)

--=20
Matthew

--=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_10_1984548527.1424362269898
Content-Type: multipart/alternative;
 boundary="----=_Part_11_1738571732.1424362269898"

------=_Part_11_1738571732.1424362269898
Content-Type: text/plain; charset=UTF-8

Better examples that permit use in initializer lists and better-defined
handling of string literals:



// char-flavored dump of "shader.vert", intervening nulls included, stops
at first EOF
const char src[] = {static_sequence<char>("shader.vert")};


// Just 0x00, 0x01, 0x02, 0x03, etc... Pass it to a constructor, too!
const uint8_t blob[] = {static_sequence<uint8_t>("blob.dat")};


// 'w','o','r','d','s',' ' ... Including nulls (if any).
const char str_a[] = {static_sequence<char>("words.txt")};


// Stops at first null, or at the first EOF then adds a null instead.
// "words words words" <- null terminated!
const char *str = static_string<char>("words.txt");


--

---
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_11_1738571732.1424362269898
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Better examples that permit use in initializer lists and b=
etter-defined handling of string literals:<br><br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><br><code class=3D"prettyp=
rint"><span style=3D"color: #800;" class=3D"styled-by-prettify">// char-fla=
vored dump of "shader.vert", intervening nulls included, stops at first EOF=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
></code><span style=3D"color: #008;" class=3D"styled-by-prettify">const</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> src</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
tatic_sequence</span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy">&lt;char&gt;</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"sh=
ader.vert"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br=
></span><br><code class=3D"prettyprint"><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// Just 0x00, 0x01, 0x02, 0x03, etc... Pass it to a=
 constructor, too!</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span></code><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> uint8_t blob</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">[]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">static_sequence</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&lt;uint8_t&gt;</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #080;" class=3D"styled-by-prettify">"blob.dat"</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)};</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">// 'w'</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">,'o','r','d','s',' ' ... Including nulls (if any).<=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> str_a</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> {static_sequence</span><span style=3D"color: #080;" cl=
ass=3D"styled-by-prettify">&lt;char&gt;</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">"words.txt"</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)};</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br><br></span><br><code class=3D"prettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// Stops at first null, or at the first E=
OF then adds a null instead.</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></code><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// "words words words"</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> &lt;- null terminated!<br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">str </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> st=
atic_string</span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
>&lt;char&gt;</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"words=
..txt"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code=
></div><br><br></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_11_1738571732.1424362269898--
------=_Part_10_1984548527.1424362269898--

.

------=_Part_1564_258614860.1424362480167
Content-Type: multipart/alternative;
 boundary="----=_Part_1565_33050492.1424362480167"

------=_Part_1565_33050492.1424362480167
Content-Type: text/plain; charset=UTF-8

Meant to add '...' after each 'static_sequence<>', but I think you get the
idea:

static_sequence<T>( file-name ) creates a comma-delimited sequence of
constants.

So, you could also do this:

template<char ...chars_>
struct charbag{};

fancy_template<
    some_type,
    charbag<static_sequence<char>("words.txt")...>
    > boom{};



--

---
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_1565_33050492.1424362480167
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Meant to add '...' after each 'static_sequence&lt;&gt;', b=
ut I think you get the idea:<br><br>static_sequence&lt;T&gt;( file-name ) c=
reates a comma-delimited sequence of constants.<br><br>So, you could also d=
o this:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">char<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">chars_</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> charbag</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br>fancy_template</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; &nbsp; some_type</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; charbag</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">static_sequence</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&lt;char&gt;</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #080;" class=3D"styled-by-prettify">"words.txt"</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)...&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> boom</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span></div></code></div><br><br><div dir=
=3D"ltr"><br></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_1565_33050492.1424362480167--
------=_Part_1564_258614860.1424362480167--

.

------=_Part_734_1468160869.1424371529217
Content-Type: multipart/alternative;
 boundary="----=_Part_735_792621253.1424371529218"

------=_Part_735_792621253.1424371529218
Content-Type: text/plain; charset=UTF-8

This kind of feature would be really nice to have. While some people may
argue its better not to embed data in the binary, sometimes it really just
makes sense to do it that way. Use cases that come to mind include 3d
applications with GPU shaders and embedded applications with firmware and
other binary data blobs. This feature has been available with assemblers
since ancient history, we should have it in C and C++ as well.

I think such a feature would make the most sense being implemented using
the processor. Then the implementation can just leverage the cpp include
path to search for the files.

Possible syntax:

//Performs \r\n vs \n conversion
const char a[] =
#include_text "some_file.txt"
;

//Import the raw bytes as a literal
const uint8_t b[] =
#include_bin "some_file.bin"
;

Endian conversion support I'm not so sure is a great idea. Most binary
blobs are not just a big array of same size integral values but contain
structure with many different integers, bytes, flags, text, etc.. Doing
proper endian conversion at that level of complexity requires external
tools.


--

---
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_735_792621253.1424371529218
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This kind of feature would be really nice to have. While s=
ome people may argue its better not to embed data in the binary, sometimes =
it really just makes sense to do it that way. Use cases that come to mind i=
nclude 3d applications with GPU shaders and embedded applications with firm=
ware and other binary data blobs. This feature has been available with asse=
mblers since ancient history, we should have it in C and C++ as well.<br><b=
r>I think such a feature would make the most sense being implemented using =
the processor. Then the implementation can just leverage the cpp include pa=
th to search for the files.<br><br>Possible syntax:<br><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #800;" class=3D"styled-by-prettify">//Performs \r\n vs \n conversion</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">#incl=
ude_text "some_file.txt"</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//I=
mport the raw bytes as a literal</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> uint8_t b</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">[]</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">#include_bin "som=
e_file.bin"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><br>Endian conversion support I'm not so sure is a great id=
ea. Most binary blobs are not just a big array of same size integral values=
 but contain structure with many different integers, bytes, flags, text, et=
c.. Doing proper endian conversion at that level of complexity requires ext=
ernal tools.<br><br><br></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_735_792621253.1424371529218--
------=_Part_734_1468160869.1424371529217--

.

On Thursday 19 February 2015 10:54:54 Matthew Woehlke wrote:
> Nothing; the user must perform an appropriate conversion at run-time,
> same as if they had read the data from a separate file at run-time. The
> low level objective is to transport *binary* data (which works for text
> also in the trivial case).

char array[] = "a";

Even if my source code is ASCII and thus the letter 'a' is 0x61, it does not
imply that the output will contain 0x61.

Try it by passing -fexec-charset=EBCDIC-US to GCC.

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

.

> This kind of feature would be really nice to have. While some people may=
=20
> argue its better not to embed data in the binary, sometimes it really jus=
t=20
> makes sense to do it that way. Use cases that come to mind include 3d=20
> applications with GPU shaders and embedded applications with firmware and=
=20
> other binary data blobs. This feature has been available with assemblers=
=20
> since ancient history, we should have it in C and C++ as well.

I think this it a problem for build system to prepare such in-code data
blobs using some tool (Qt's qmake and qrc are prominent example of
such). Anyway, you would have to compile your shader code or firmware
using external compiler, so you still need an advanced build system of
some kind in order to get fully automatic build.

> I think such a feature would make the most sense being implemented using=
=20
> the processor. Then the implementation can just leverage the cpp include=
=20
> path to search for the files.

Of course reusing existing concept is the easiest option, but that
doesn't sound sane to put binary blobs into include path.

> Possible syntax:
>=20
> //Performs \r\n vs \n conversion
> const char a[] =3D
> #include_text "some_file.txt"
> ;

What are exact rules of the conversion on different platforms and why is
it important to have such a conversion built-in? Moreover, you should
also provide #include_wtext for getting text into wchar_t[], but that
encoding should have file being included? You'll have to put whole ICU
library into C preprocessor to deal with all that different encodings
and Unicode-related features (like BOMs, for example).

> //Import the raw bytes as a literal
> const uint8_t b[] =3D
> #include_bin "some_file.bin"
> ;

Apart of encoding issues, splitting a statement like that looks a bit ugly.

    const uint8_t b[] =3D __INCLUDE_FILE_CONTENTS("some_file.bin");

The above is a bit nicer, but still looks like and ad-hoc solution for
not so common problem.

To sum up, I think that plain binary inclusion is the only one option
which should be considered if this proposal is ever going to be accepted.

=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.

--=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 2015-02-19 15:42, Pavel Kretov wrote:
> I think this it a problem for build system to prepare such in-code data
> blobs using some tool (Qt's qmake and qrc are prominent example of
> such). Anyway, you would have to compile your shader code or firmware
> using external compiler, so you still need an advanced build system of
> some kind in order to get fully automatic build.

You mean like... https://www.opengl.org/wiki/GLAPI/glShaderSource ?

Shader compilation (at least every time *I've* ever dealt with GLSL)
happens *at run time*. Ergo, your statement is false, unless you define
"external compiler" as "the OpenGL library (that you are using anyway)".

Image resources are similar; decoding happens *at run time* from a raw
blob that is exactly the original image file.

> Of course reusing existing concept is the easiest option, but that
> doesn't sound sane to put binary blobs into include path.

Why not? :-) I'd happily do so if I had this feature.

> What are exact rules of the conversion on different platforms and why is
> it important to have such a conversion built-in?

Er... no. The rule is "don't convert". (Once we have that case, we can
think about others.)

There may or may not be a conversion of file contents to something that
the compiler can work with, but that's specific to the compiler, and
presumably the compiler knows how to do it.

> Apart of encoding issues, splitting a statement like that looks a bit ugly.
>
>     const uint8_t b[] = __INCLUDE_FILE_CONTENTS("some_file.bin");

Agreed... though I'm less convinced that I was originally that this
should even be in the domain of the preprocessor. I do agree however it
should be __pragma-like rather than #pragma like (unless it supports both).

> The above is a bit nicer, but still looks like and ad-hoc solution for
> not so common problem.

I beg to differ; many, if not most, GUI applications I have written or
worked on have resources.

> To sum up, I think that plain binary inclusion is the only one option
> which should be considered if this proposal is ever going to be accepted.

I would start there, yes. If that's accepted, we can always revisit
doing fancier things.

--
Matthew

--

---
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 19 February 2015 at 22:59, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> On 2015-02-19 15:42, Pavel Kretov wrote:
>> I think this it a problem for build system to prepare such in-code data
>> blobs using some tool (Qt's qmake and qrc are prominent example of
>> such). Anyway, you would have to compile your shader code or firmware
>> using external compiler, so you still need an advanced build system of
>> some kind in order to get fully automatic build.
>
> You mean like... https://www.opengl.org/wiki/GLAPI/glShaderSource ?
>
> Shader compilation (at least every time *I've* ever dealt with GLSL)
> happens *at run time*. Ergo, your statement is false, unless you define

You can precompile shaders so that they don't need to be compiled at run time,
so the statement is far from false. The mechanisms for doing that, and using
such precompiled shaders, may be implementation-specific instead of officially
sanctioned by khronos, but that doesn't mean it can't be done.

--

---
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 2015-02-19 16:03, Ville Voutilainen wrote:
> On 19 February 2015 at 22:59, Matthew Woehlke wrote:
>> On 2015-02-19 15:42, Pavel Kretov wrote:
>>> I think this it a problem for build system to prepare such in-code data
>>> blobs using some tool (Qt's qmake and qrc are prominent example of
>>> such). Anyway, you would have to compile your shader code or firmware
>>> using external compiler, so you still need an advanced build system of
>>> some kind in order to get fully automatic build.
>>
>> You mean like... https://www.opengl.org/wiki/GLAPI/glShaderSource ?
>>
>> Shader compilation (at least every time *I've* ever dealt with GLSL)
>> happens *at run time*. Ergo, your statement is false [...]
>
> You can precompile shaders so that they don't need to be compiled at run time,

The key word there is "can", as in, not "must".

> so the statement is far from false.

Please pardon the pedantism, but...

I took Pavel's comments as claiming that one of the original rationales
given for the feature never actually occurs. In fact, it *does* occur,
and I personally have "experienced" it.

This feature plus run-time compilation would give us an end-to-end
portable way to load GLSL shaders without nasty means of embedding the
source in C++ (i.e. as string literals). Pavel stated that it would not
because an external GLSL compiler is *required* ("*have to* compile",
"*need* an advanced build system" - emphasis added). Such statements, as
I can attest from personal experience, *are* in fact false.

I would find the proposed feature useful. I would, in fact, very likely
find it useful for the specific case that Pavel claims does not occur.
Since such claims are naturally directed at undermining the chances of
the feature being accepted, and since I would like and use the feature,
I feel it's important to refute such claims.

Related: Neither pre-compilation nor other resource systems are
portable. (Which brings an interesting point; if you insist on using
non-portable methods to compile shaders, it's perhaps not so surprising
that you'd have the attitude "what's another non-portable method to
marshall the object code from a build system artifact into the running
application?".)

--
Matthew

--

---
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 19 February 2015 at 23:50, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> This feature plus run-time compilation would give us an end-to-end
> portable way to load GLSL shaders without nasty means of embedding the
> source in C++ (i.e. as string literals). Pavel stated that it would not
> because an external GLSL compiler is *required* ("*have to* compile",
> "*need* an advanced build system" - emphasis added). Such statements, as
> I can attest from personal experience, *are* in fact false.

Correct, pardon the confusion.

> I would find the proposed feature useful. I would, in fact, very likely
> find it useful for the specific case that Pavel claims does not occur.

Ack. :)

> Related: Neither pre-compilation nor other resource systems are
> portable. (Which brings an interesting point; if you insist on using
> non-portable methods to compile shaders, it's perhaps not so surprising
> that you'd have the attitude "what's another non-portable method to
> marshall the object code from a build system artifact into the running
> application?".)


Maybe. I personally prefer portable solutions over non-portable ones. :)

--

---
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 2015-02-19 16:53, Ville Voutilainen wrote:
> On 19 February 2015 at 23:50, Matthew Woehlke wrote:
>> [pedantism]
>
> Correct, pardon the confusion.

Happily pardoned :-).

>> Related: Neither pre-compilation nor other resource systems are
>> portable. (Which brings an interesting point; if you insist on using
>> non-portable methods to compile shaders, it's perhaps not so surprising
>> that you'd have the attitude "what's another non-portable method to
>> marshall the object code from a build system artifact into the running
>> application?".)
>
> Maybe. I personally prefer portable solutions over non-portable ones. :)

Likewise. I wasn't applying the above to us (apologies if it was implied
otherwise), more "realizing out loud" if you will that it may help
explain why some (other) people don't seem to grasp why this would be
useful.

--
Matthew

--

---
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_171_1002254638.1424385740527
Content-Type: multipart/alternative;
 boundary="----=_Part_172_31973798.1424385740527"

------=_Part_172_31973798.1424385740527
Content-Type: text/plain; charset=UTF-8



On Thursday, February 19, 2015 at 3:42:30 PM UTC-5, Pavel Kretov wrote:
>
> > This kind of feature would be really nice to have. While some people may
> > argue its better not to embed data in the binary, sometimes it really
> just
> > makes sense to do it that way. Use cases that come to mind include 3d
> > applications with GPU shaders and embedded applications with firmware
> and
> > other binary data blobs. This feature has been available with assemblers
> > since ancient history, we should have it in C and C++ as well.
>
> I think this it a problem for build system to prepare such in-code data
> blobs using some tool (Qt's qmake and qrc are prominent example of
> such). Anyway, you would have to compile your shader code or firmware
> using external compiler, so you still need an advanced build system of
> some kind in order to get fully automatic build.
>

Most of the time you compile shaders at runtime because you don't know what
kind of GPU hardware your users will have. For situations where you know
the hardware, such as console development pre-compiling the shaders can
make sense but at that stage it may also make sense to just binary include
those pre-compiled shader files into your application instead of writing
filesystem routines to load them.


> > I think such a feature would make the most sense being implemented using
> > the processor. Then the implementation can just leverage the cpp include
> > path to search for the files.
>
> Of course reusing existing concept is the easiest option, but that
> doesn't sound sane to put binary blobs into include path.
>

It seems like the best option to me. If we do not leverage the include path
for this then we have invent yet another path for binary imports. I don't
see any problem with adding the path for your binary imports to the include
path in your build system. Anyway that's what we are doing, including
contents of a file into our translation unit as a binary string literal.



> Apart of encoding issues, splitting a statement like that looks a bit
> ugly.
>
>     const uint8_t b[] = __INCLUDE_FILE_CONTENTS("some_file.bin");
>
> The above is a bit nicer, but still looks like and ad-hoc solution for
> not so common problem.
>

That style would be fine too, and probably easier to use.

I still think this is a task for the preprocessor and not the C++ compiler.
The preprocessor already has support for #include and include paths. It can
simply expand the macro into a string literal and then the C++ compiler is
none the wiser. Imported binary blobs can go anywhere you'd directly write
a string literal. Technically, once we get to the C++ compiler stage there
is no include path anymore because all includes are resolved by the
preprocessor. Finally, doing the work in the preprocessor makes the feature
automatically available for both C and C++.

Does anyone have a good reason why this feature does not belong in the
preprocessor?

One reason I think of is performance. If the binary blob is somewhat large,
its textual representation in the translation unit as an array initializer
and/or string literal will be larger than the binary blob itself by a
factor of 4 or more. Converting the blob to C code text and then back to
its original binary form after compilation is wasted work.

Implementations might be able to work around this issue if we allow that
the output of the preprocessor can be an implementation specific string
literal syntax (e.g. some macro wrapping a native endian 8 byte size count,
followed by the raw binary data right in the generated translation unit).
Avoiding the roundtrip conversion to text and back.


> To sum up, I think that plain binary inclusion is the only one option
> which should be considered if this proposal is ever going to be accepted.
>

That's fair enough, just being able to import binary blobs with no extra
logic would be enough for me.

One major issue I can think of regarding differentiating text from binary
data which is null termination. When we import a text blob, we probably
would like to have a null terminator added at the end so that the text can
be used with legacy C api's. GPU shaders in OpenGL would require this.

For binary blobs, we probably do not want a null terminator included. That
way the array we initialize will have the exact same size as the blob and
we can load it into memory, do checksums, etc.. without being plagued by
sizeof() -1 bugs everywhere.

If only one binary import method is to be proposed, then it must always
append a null terminator giving us C compatibility for text and only
sizeof()-1 headaches for binary.

--

---
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_172_31973798.1424385740527
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, February 19, 2015 at 3:42:30 PM UTC-5=
, Pavel Kretov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; This=
 kind of feature would be really nice to have. While some people may=20
<br>&gt; argue its better not to embed data in the binary, sometimes it rea=
lly just=20
<br>&gt; makes sense to do it that way. Use cases that come to mind include=
 3d=20
<br>&gt; applications with GPU shaders and embedded applications with firmw=
are and=20
<br>&gt; other binary data blobs. This feature has been available with asse=
mblers=20
<br>&gt; since ancient history, we should have it in C and C++ as well.
<br>
<br>I think this it a problem for build system to prepare such in-code data
<br>blobs using some tool (Qt's qmake and qrc are prominent example of
<br>such). Anyway, you would have to compile your shader code or firmware
<br>using external compiler, so you still need an advanced build system of
<br>some kind in order to get fully automatic build.
<br></blockquote><div><br>Most of the time you compile shaders at runtime b=
ecause you don't know what kind of GPU hardware your users will have. For s=
ituations where you know the hardware, such as console development pre-comp=
iling the shaders can make sense but at that stage it may also make sense t=
o just binary include those pre-compiled shader files into your application=
 instead of writing filesystem routines to load them.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; I think such a feature would make the most sense being implemented=
 using=20
<br>&gt; the processor. Then the implementation can just leverage the cpp i=
nclude=20
<br>&gt; path to search for the files.
<br>
<br>Of course reusing existing concept is the easiest option, but that
<br>doesn't sound sane to put binary blobs into include path.
<br></blockquote><div><br>It seems like the best option to me. If we do not=
 leverage the include path for this then we have invent yet another path fo=
r binary imports. I don't see any problem with adding the path for your bin=
ary imports to the include path in your build system. Anyway that's what we=
 are doing, including contents of a file into our translation unit as a bin=
ary string literal.<br>&nbsp;<br></div><br><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">
<br>Apart of encoding issues, splitting a statement like that looks a bit u=
gly.
<br>
<br>&nbsp; &nbsp; const uint8_t b[] =3D __INCLUDE_FILE_CONTENTS("some_<wbr>=
file.bin");
<br>
<br>The above is a bit nicer, but still looks like and ad-hoc solution for
<br>not so common problem.
<br></blockquote><div><br>That style would be fine too, and probably easier=
 to use. <br><br>I still think this is a task for the preprocessor and not =
the C++ compiler. The preprocessor already has support for #include and inc=
lude paths. It can simply expand the macro into a string literal and then t=
he C++ compiler is none the wiser. Imported binary blobs can go anywhere yo=
u'd directly write a string literal. Technically, once we get to the C++ co=
mpiler stage there is no include path anymore because all includes are reso=
lved by the preprocessor. Finally, doing the work in the preprocessor makes=
 the feature automatically available for both C and C++.<br><br>Does anyone=
 have a good reason why this feature does not belong in the preprocessor? <=
br><br>One reason I think of is performance. If the binary blob is somewhat=
 large, its textual representation in the translation unit as an array init=
ializer and/or string literal will be larger than the binary blob itself by=
 a factor of 4 or more. Converting the blob to C code text and then back to=
 its original binary form after compilation is wasted work.<br><br>Implemen=
tations might be able to work around this issue if we allow that the output=
 of the preprocessor can be an implementation specific string literal synta=
x (e.g. some macro wrapping a native endian 8 byte size count, followed by =
the raw binary data right in the generated translation unit). Avoiding the =
roundtrip conversion to text and back.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
<br>To sum up, I think that plain binary inclusion is the only one option
<br>which should be considered if this proposal is ever going to be accepte=
d.
<br></blockquote><div><br>That's fair enough, just being able to import bin=
ary blobs with no extra logic would be enough for me.<br><br>One major issu=
e I can think of regarding differentiating text from binary data which is
 null termination. When we import a text blob, we probably would like to
 have a null terminator added at the end so that the text can be used=20
with legacy C api's. GPU shaders in OpenGL would require this.<br><br>For b=
inary blobs, we probably do not want a null terminator included.=20
That way the array we initialize will have the exact same size as the=20
blob and we can load it into memory, do checksums, etc.. without being=20
plagued by sizeof() -1 bugs everywhere.<br><br>If only one binary import me=
thod is to be proposed, then it must always append a null terminator giving=
 us C compatibility for text and only sizeof()-1 headaches for binary.<br><=
br></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_172_31973798.1424385740527--
------=_Part_171_1002254638.1424385740527--

.

On 2015-02-19 17:42, Matthew Fioravante wrote:
> Does anyone have a good reason why this feature does not belong in the
> preprocessor?

You more or less said it; performance. (Also, potentially, ease of
implementation.) Depending on the compiler, it may be much easier to
simply copy the file contents directly from the input file to the
process that's writing the output object file.

As previously stated though I'd be inclined to not legislate this, but
rather specify that the feature behaves "as if" done by the preprocessor
and leave it to the compiler vendors whether or not that's how they
*actually* want to implement it.

> One major issue I can think of regarding differentiating text from binary
> data which is null termination. When we import a text blob, we probably
> would like to have a null terminator added at the end so that the text can
> be used with legacy C api's. GPU shaders in OpenGL would require this.

Hmm... good point. I was sort of assuming the presence of a null
terminator, but you're right that for "pure" binary data (say, image
files) this could be undesirable. That being the case, this may be a
good way to handle line endings also.

IOW, one 'mode' does line ending translation and null terminates, the
other does neither.

> If only one binary import method is to be proposed, then it must always
> append a null terminator giving us C compatibility for text and only
> sizeof()-1 headaches for binary.

Agreed.

--
Matthew

--

---
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_304_989804709.1424400847474
Content-Type: multipart/alternative;
 boundary="----=_Part_305_1239414501.1424400847475"

------=_Part_305_1239414501.1424400847475
Content-Type: text/plain; charset=UTF-8



On Thursday, February 19, 2015 at 7:04:53 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-02-19 17:42, Matthew Fioravante wrote:
> > Does anyone have a good reason why this feature does not belong in the
> > preprocessor?
>
> You more or less said it; performance. (Also, potentially, ease of
> implementation.) Depending on the compiler, it may be much easier to
> simply copy the file contents directly from the input file to the
> process that's writing the output object file.
>
> As previously stated though I'd be inclined to not legislate this, but
> rather specify that the feature behaves "as if" done by the preprocessor
> and leave it to the compiler vendors whether or not that's how they
> *actually* want to implement it.
>

Maybe the requirements should be more specific. What happens if I just
preprocess a .cpp file with cpp or gcc -E? Should I expect the output file
to have expanded the binary file into textual C array syntax?
Implementation defined?

Even if the feature specification is technically supposed to be supported
by the preprocessor, if you just compile a .cpp file into an object file
using your compiler, the implementation is free to optimize to optimize the
binary inclusion method to bypass the textual transformation and do a
direct bit copy from the source file to the resulting object file.

>
> > One major issue I can think of regarding differentiating text from
> binary
> > data which is null termination. When we import a text blob, we probably
> > would like to have a null terminator added at the end so that the text
> can
> > be used with legacy C api's. GPU shaders in OpenGL would require this.
>
> Hmm... good point. I was sort of assuming the presence of a null
> terminator, but you're right that for "pure" binary data (say, image
> files) this could be undesirable.


One problem with null termination is that we need to be told the intended
character type of the data (char, char16_t, char32_t, wchar_t) in order to
know how many bytes to reserve for the null terminator and the type of the
resulting string literal expression generated by the macro.



> That being the case, this may be a
> good way to handle line endings also.
>

What if the user wants null termination but doesn't want line ending
processing?

Maybe line endings, endian swapping, casting to array<T, sizeof(literal) /
sizeof(T)>, string_view, string_literal<sizeof(literal)> etc.. can all be
done in the library. In particular constexpr functions manipulating
string_literal<N> objects

template <typename CharT, size_t N>
constexpr auto remove(string_literal<N, CharT> lit, CharT c) {
  auto nc = count(lit.begin(), lit.end(), c);
  string_literal<N-nc, CharT> ret;
  copy_if(lit.begin(), lit.end(), ret.begin(), [c](auto x) { return x != c;
});
  return ret;
}

auto norm_text = remove(__INCLUDE_TEXT(char, "some_file.txt"), '\r');





>
> IOW, one 'mode' does line ending translation and null terminates, the
> other does neither.


The text routine needs type information to correctly allocate the null.


constexpr auto data = __INCLUDE_BIN("some_file.bin");
constexpr auto text = __INCLUDE_TEXT(char,"some_file.txt");

//decltype(text) == const char [/*sizeof file + sizeof(char)*/]
//decltype(data) == const char [/*sizeof file*/] //or maybe unsigned char

The binary routine could also use type information which can be useful if
you want signed of unsigned bytes:

constexpr auto data = __INCLUDE_BIN(uint8_t,"some_file.bin");

A library extension could take this array and cast it to and array of type
T for some basic type like a 3d vector of floats. It could also perform
endian conversion. There are a lot of possibilities. You could even write
constexpr functions to widen a packed struct you loaded from the file into
an array of T with native alignment all at compile time with error checking
on the file size. All of these possibilities come into play if we just have
an __INCLUDE_BIN() macro.

 __INCLUDE_TEXT should expand to a string literal.

//file.bin contains the text "file"


__INCLUDE_TEXT("file.txt");
"file"; //<-Produces a string literal

The reason for this is that now we can paste string literals together,
which comes for free from the behavior of string literals.

constexpr auto document = "Common Header\n"
__INCLUDE_TXT("section1.txt") "\n"
__INCLUDE_TXT("section2.txt") "\n"
"Common Footer\n";

The preprocessor would load the 2 files and replace the macros with the
contents of each file. The C++ compiler is left with 6 string literals
which it already knows how to concatenate together.

The only compatible way to implement __INCLUDE_BIN() is to replace the
macro with an array initialization.

__INCLUDE_BIN("file.bin");
{ 'f', 'i', 'l', 'e' }; //<-Behaves as if file contents substituted using
array syntax

This would mean you can't paste together multiple __INCLUDE_BIN()
expressions like you can with __INCLUDE_TEXT(). I think the sensible way to
allow for that would be to invent a new literal prefix or suffix to
generate string literals without a null terminator.

auto x = "\x00\x0A"b "\x0B\x01"b;
//dectype(x) == char[4];
//x == { 0, 0x0A, 0x0B, 1 };

Now __INCLUDE_BIN() could expand to a b suffix literal and we could again
leverage string literal concatenation to paste together files and inline
binary text.

This proposed feature has a lot of utility for operating systems, embedded
programming, and device drivers. For example, a kernel module could use
this feature to easily embed a firmware or microcode code image.

Game companies could use this to optimize loading time for crucial game
assets.  Being able to process the contents of the files at compile time
allows for compile time parsing of the file into C++ data structures.

One could put all of their compile time resources into a separate shared
library, minimizing the compile time overhead of using this tool as only
the library needs to be rebuilt.


> > If only one binary import method is to be proposed, then it must always
> > append a null terminator giving us C compatibility for text and only
> > sizeof()-1 headaches for binary.
>
> Agreed.
>
> --
> Matthew
>
>

--

---
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_305_1239414501.1424400847475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, February 19, 2015 at 7:04:53 PM UTC-5=
, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 201=
5-02-19 17:42, Matthew Fioravante wrote:
<br>&gt; Does anyone have a good reason why this feature does not belong in=
 the=20
<br>&gt; preprocessor?=20
<br>
<br>You more or less said it; performance. (Also, potentially, ease of
<br>implementation.) Depending on the compiler, it may be much easier to
<br>simply copy the file contents directly from the input file to the
<br>process that's writing the output object file.
<br>
<br>As previously stated though I'd be inclined to not legislate this, but
<br>rather specify that the feature behaves "as if" done by the preprocesso=
r
<br>and leave it to the compiler vendors whether or not that's how they
<br>*actually* want to implement it.
<br></blockquote><div><br></div><div>Maybe the requirements should be more =
specific. What happens if I just preprocess a .cpp file with cpp or gcc -E?=
 Should I expect the output file to have expanded the binary file into text=
ual C array syntax? Implementation defined?</div><div><br></div><div>Even i=
f the feature specification is technically supposed to be supported by the =
preprocessor, if you just compile a .cpp file into an object file using you=
r compiler, the implementation is free to optimize to optimize the binary i=
nclusion method to bypass the textual transformation and do a direct bit co=
py from the source file to the resulting object file.</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
<br>&gt; One major issue I can think of regarding differentiating text from=
 binary=20
<br>&gt; data which is null termination. When we import a text blob, we pro=
bably=20
<br>&gt; would like to have a null terminator added at the end so that the =
text can=20
<br>&gt; be used with legacy C api's. GPU shaders in OpenGL would require t=
his.
<br>
<br>Hmm... good point. I was sort of assuming the presence of a null
<br>terminator, but you're right that for "pure" binary data (say, image
<br>files) this could be undesirable. </blockquote><div><br></div><div>One =
problem with null termination is that we need to be told the intended chara=
cter type of the data (char, char16_t, char32_t, wchar_t) in order to know =
how many bytes to reserve for the null terminator and the type of the resul=
ting string literal expression generated by the macro.</div><div><br></div>=
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">That being th=
e case, this may be a
<br>good way to handle line endings also.
<br></blockquote><div><br></div><div>What if the user wants null terminatio=
n but doesn't want line ending processing?</div><div><br></div><div>Maybe l=
ine endings, endian swapping, casting to array&lt;T, sizeof(literal) / size=
of(T)&gt;, string_view, string_literal&lt;sizeof(literal)&gt; etc.. can all=
 be done in the library. In particular constexpr functions manipulating str=
ing_literal&lt;N&gt; objects</div><div><br></div><div><div class=3D"prettyp=
rint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word;=
 background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">CharT</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> size_t N</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> remove</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">st=
ring_literal</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">N</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">CharT</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> lit</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><font color=3D"#000088"><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">CharT</span></font><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><font color=3D"#666600"><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></font><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">&nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> nc </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> count</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">lit</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> lit</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><font color=3D"#008800"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">c</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></font><span style=3D"color: #000;" class=3D"styled-by-=
prettify">&nbsp; string_literal</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">N</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">-</span><span style=3D"color: #000;" class=3D"styled-by-prettify">nc<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">CharT</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> ret</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; copy_if</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">lit</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">begin</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> lit</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">end</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> ret</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">begin</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">](</span><font=
 color=3D"#000088"><span style=3D"color: #008;" class=3D"styled-by-prettify=
">auto</span></font><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> c</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">});</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> ret</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> norm_text </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> remove</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>__INCLUDE_TEXT</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">char=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"some_file.txt"</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
080;" class=3D"styled-by-prettify">'\r'</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br></span></div></code></div><br><br></div><div>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>IOW, one 'mode' does line ending translation and null terminates, the
<br>other does neither.&nbsp;</blockquote><div><br></div><div>The text rout=
ine needs type information to correctly allocate the null.</div><div><br></=
div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187=
, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><font color=3D"#000088"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span></font><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> data </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> __INCLUDE_BIN</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">"some_file.bin"</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><font color=3D"#000088"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span></font><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> text </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> __INCLUDE_TEXT</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">char</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #080;" class=3D"styled-by-p=
rettify">"some_file.txt"</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">//decltype(text) =3D=3D const char [/*sizeof file + sizeof(char)*/]</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">//decltype(data) =3D=
=3D const char [/*sizeof file*/] //or maybe unsigned char</span></div></cod=
e></div><br>The binary routine could also use type information which can be=
 useful if you want signed of unsigned bytes:</div><div><br></div><div><div=
 class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-=
wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> data </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> __INCLUDE_BIN</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">uint8_t</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy">"some_file.bin"</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span></font></div></code></div><br>A library extension could t=
ake this array and cast it to and array of type T for some basic type like =
a 3d vector of floats. It could also perform endian conversion. There are a=
 lot of possibilities. You could even write constexpr functions to widen a =
packed struct you loaded from the file into an array of T with native align=
ment all at compile time with error checking on the file size. All of these=
 possibilities come into play if we just have an __INCLUDE_BIN() macro.</di=
v><div><br></div><div>&nbsp;__INCLUDE_TEXT should expand to a string litera=
l.</div><div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px=
 solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250=
, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><fo=
nt color=3D"#660066"><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">//file.bin contains the text "file"</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br><br>__INCLUDE_TEXT</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"file.txt"</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"file"</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//&lt;-Produces a string literal</span></font></div></code></div><br>The =
reason for this is that now we can paste string literals together, which co=
mes for free from the behavior of string literals.</div><div><br></div><div=
><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); =
word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> document </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"C=
ommon Header\n"</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>__INCLUDE_TXT</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">"section1.txt"</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">"\n"</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>__INCLUDE_TXT=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">"section2.txt"</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">"\n"</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #080;"=
 class=3D"styled-by-prettify">"Common Footer\n"</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span></div></code></div><br>The pre=
processor would load the 2 files and replace the macros with the contents o=
f each file. The C++ compiler is left with 6 string literals which it alrea=
dy knows how to concatenate together.</div><div><br></div><div>The only com=
patible way to implement __INCLUDE_BIN() is to replace the macro with an ar=
ray initialization.</div><div><br></div><div><span style=3D"color: rgb(102,=
 0, 102); font-family: monospace; font-size: 13.1428575515747px; background=
-color: rgb(250, 250, 250);">__INCLUDE_BIN("file.bin");&nbsp;</span><br sty=
le=3D"color: rgb(102, 0, 102); font-family: monospace; font-size: 13.142857=
5515747px; background-color: rgb(250, 250, 250);"><span style=3D"color: rgb=
(102, 0, 102); font-family: monospace; font-size: 13.1428575515747px; backg=
round-color: rgb(250, 250, 250);">{ 'f', 'i', 'l', 'e' }; //&lt;-Behaves as=
 if file contents substituted using array syntax</span><br style=3D"color: =
rgb(102, 0, 102); font-family: monospace; font-size: 13.1428575515747px; ba=
ckground-color: rgb(250, 250, 250);"></div><div><br></div><div>This would m=
ean you can't paste together multiple __INCLUDE_BIN() expressions like you =
can with __INCLUDE_TEXT(). I think the sensible way to allow for that would=
 be to invent a new literal prefix or suffix to generate string literals wi=
thout a null terminator.</div><div><br></div><div><div class=3D"prettyprint=
" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; bac=
kground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"\=
x00\x0A"</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b =
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"\x0B\x01"=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">//dectype(x) =3D=3D char[4];</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">//x =3D=3D { 0, 0x0A, =
0x0B, 1 };</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span></font></div></code></div><div><br></div>Now __INCLUDE_BIN() cou=
ld expand to a b suffix literal and we could again leverage string literal =
concatenation to paste together files and inline binary text.<br><br></div>=
<div>This proposed feature has a lot of utility for operating systems, embe=
dded programming, and device drivers. For example, a kernel module could us=
e this feature to easily embed a firmware or microcode code image.</div><di=
v><br></div><div>Game companies could use this to optimize loading time for=
 crucial game assets. &nbsp;Being able to process the contents of the files=
 at compile time allows for compile time parsing of the file into C++ data =
structures.</div><div><br></div><div>One could put all of their compile tim=
e resources into a separate shared library, minimizing the compile time ove=
rhead of using this tool as only the library needs to be rebuilt.</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; If only one binary import method is to be proposed, then it must a=
lways=20
<br>&gt; append a null terminator giving us C compatibility for text and on=
ly=20
<br>&gt; sizeof()-1 headaches for binary.
<br>
<br>Agreed.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></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_305_1239414501.1424400847475--
------=_Part_304_989804709.1424400847474--

.

------=_Part_372_853530312.1424401510922
Content-Type: multipart/alternative;
 boundary="----=_Part_373_93191824.1424401510922"

------=_Part_373_93191824.1424401510922
Content-Type: text/plain; charset=UTF-8

Another alternative could be to just use string literal prefixes and
suffixes.

__INCLUDE_FILE(X"file.txt"Y); //file.txt contains the text "file"
X"\x66\x69\x6C\x65"Y; //Prefix and suffix applied to the resulting string
literal

With the above mentioned b literal suffix for a non-null terminated
literal, we don't need a separate __INCLUDE_BIN

auto fw = __INCLUDE_FILE("firmware.bin"b);
auto fw = "\x01\x00..."b; //<-Macro expands to this



--

---
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_373_93191824.1424401510922
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Another alternative could be to just use string literal pr=
efixes and suffixes.<div><br></div><div><div class=3D"prettyprint" style=3D=
"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-co=
lor: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #000;" class=3D"styled-by-prettify">__INCLUD=
E_FILE</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">X</span><span=
 style=3D"color: #080;" class=3D"styled-by-prettify">"file.txt"</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">Y</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">//file.txt contains the text "file"</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>X</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"\x66\x69\x6C\x65"</span><fo=
nt color=3D"#666600"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">Y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">//Prefix and suffix app=
lied to the resulting string literal</span></font></div></code></div><br>Wi=
th the above mentioned b literal suffix for a non-null terminated literal, =
we don't need a separate __INCLUDE_BIN</div><div><br></div><div><div class=
=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> fw </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _=
_INCLUDE_FILE</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"firmw=
are.bin"</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b<=
/span><font color=3D"#008800"><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fw </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"\x01\x00..."</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">b</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//&lt;-</span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">Macro expands to this</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span></font></div></code></div><b=
r><br></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_373_93191824.1424401510922--
------=_Part_372_853530312.1424401510922--

.

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

The unfortunate issue with using the preprocessor to construct a string
literal is that the standard requires a minimum character limit for string
literals and literals too long do in fact trigger diagnostics in literally
every major in production compiler I've ever used (which is like 20.)

On Thu, Feb 19, 2015 at 10:05 PM, Matthew Fioravante <fmatthew5876@gmail.com
> wrote:

> Another alternative could be to just use string literal prefixes and
> suffixes.
>
> __INCLUDE_FILE(X"file.txt"Y); //file.txt contains the text "file"
> X"\x66\x69\x6C\x65"Y; //Prefix and suffix applied to the resulting string
> literal
>
> With the above mentioned b literal suffix for a non-null terminated
> literal, we don't need a separate __INCLUDE_BIN
>
> auto fw = __INCLUDE_FILE("firmware.bin"b);
> auto fw = "\x01\x00..."b; //<-Macro expands to this
>
>
>
>  --
>
> ---
> 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/.
>

--

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

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

<div dir=3D"ltr"><div>The unfortunate issue with using the preprocessor to =
construct a string literal is that the standard requires a minimum characte=
r limit for string literals and literals too long do in fact trigger diagno=
stics in literally<br></div>every major in production compiler I&#39;ve eve=
r used (which is like 20.)<br></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Thu, Feb 19, 2015 at 10:05 PM, Matthew Fioravante <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_bla=
nk">fmatthew5876@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">Another alternative could be to just use string li=
teral prefixes and suffixes.<div><br></div><div><div style=3D"border:1px so=
lid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)=
"><code><div><span style=3D"color:#000">__INCLUDE_FILE</span><span style=3D=
"color:#660">(</span><span style=3D"color:#000">X</span><span style=3D"colo=
r:#080">&quot;file.txt&quot;</span><span style=3D"color:#000">Y</span><span=
 style=3D"color:#660">);</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#800">//file.txt contains the text &quot;file&quot;</span><span=
 style=3D"color:#000"><br>X</span><span style=3D"color:#080">&quot;\x66\x69=
\x6C\x65&quot;</span><font color=3D"#666600"><span style=3D"color:#000">Y</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#800">//Prefix and suffix applied to the resulting str=
ing literal</span></font></div></code></div><br>With the above mentioned b =
literal suffix for a non-null terminated literal, we don&#39;t need a separ=
ate __INCLUDE_BIN</div><div><br></div><div><div style=3D"border:1px solid r=
gb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><co=
de><div><span style=3D"color:#008">auto</span><span style=3D"color:#000"> f=
w </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> _=
_INCLUDE_FILE</span><span style=3D"color:#660">(</span><span style=3D"color=
:#080">&quot;firmware.bin&quot;</span><span style=3D"color:#000">b</span><f=
ont color=3D"#008800"><span style=3D"color:#660">);</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#008">auto</span><span style=3D"c=
olor:#000"> fw </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#080">&quot;\x01\x00...&quot;</span=
><span style=3D"color:#000">b</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#800">//&lt;-</span><sp=
an style=3D"color:#800">Macro expands to this</span><span style=3D"color:#0=
00"><br><br></span></font></div></code></div><br><br></div></div><div class=
=3D"HOEnZb"><div class=3D"h5">

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

--089e0158ab6a3109e3050f7fcc58--

.

------=_Part_688_1300879815.1424437931698
Content-Type: multipart/alternative;
 boundary="----=_Part_689_356040598.1424437931698"

------=_Part_689_356040598.1424437931698
Content-Type: text/plain; charset=UTF-8

Is there anything against a matlab-like "load"?

const char *str = load_static_string<char>("filename.txt");

const int ints[] = {load_static_sequence<int>("ints.dat")...};

Any sanely-written compiler should have FS gunk opaquely isolated to a
separate subsystem anyway (basic SOC, this isn't hard stuff), so this is
doable from my point of view.

IMO, its easier to just inject symbols: No additional parsing needed --
faster and type-safe, too.

Lookup rules? Let the tools decide what a "file" is (#include essentially
leaves this undefined, anyway). These are just names.

Endianness? Again, let the tools decide. Source files are not makefiles.

No need to add more slow text-based tools to the preprocessor.

--

---
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_689_356040598.1424437931698
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is there anything against a matlab-like "load"?<br><br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">str </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> load_static_string</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">&lt;char&gt;</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"filename.txt"</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ints</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">[]</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">load_static_sequence</span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"st=
yled-by-prettify">"ints.dat"</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)...};</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span></div></code></div><br>Any sanely-written compiler=
 should have FS gunk opaquely isolated to a separate subsystem anyway (basi=
c SOC, this isn't hard stuff), so this is doable from my point of view.<br>=
<br>IMO, its easier to just inject symbols: No additional parsing needed --=
 faster and type-safe, too.<br><br>Lookup rules? Let the tools decide what =
a "file" is (#include essentially leaves this undefined, anyway). These are=
 just names.<br><br>Endianness? Again, let the tools decide. Source files a=
re not makefiles.<br><br>No need to add more slow text-based tools to the p=
reprocessor.<br></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_689_356040598.1424437931698--
------=_Part_688_1300879815.1424437931698--

.

> You mean like... https://www.opengl.org/wiki/GLAPI/glShaderSource ?
>=20
> Shader compilation (at least every time *I've* ever dealt with GLSL)
> happens *at run time*. Ergo, your statement is false, unless you define
> "external compiler" as "the OpenGL library (that you are using anyway)".

Unfortunately, I have no experience with GLSL (my fault, I think I
should), but Microsoft's DirectX shaders require building by external
compiler [1] (specifically, fxc), at least they did at the time I was
working in a gamedev company).

[1]:
https://msdn.microsoft.com/ru-ru/library/windows/desktop/bb509633%28v=3Dvs.=
85%29.aspx

> Image resources are similar; decoding happens *at run time* from a raw
> blob that is exactly the original image file.

If you read my answer again, you'll find out I was talking about
*shaders* and *firmware* blobs. As for images my statement is obviously
not true. I hope, you're not going to blob-include XPM image files? :)

> Er... no. The rule is "don't convert". (Once we have that case, we can
> think about others.)

I think the rule should be "binary-only blobs". Text blob-inclusion may
be way too unportable. (May be so is binary if there still any
seven-bits-in-a-byte platform currently in use).

> There may or may not be a conversion of file contents to something that
> the compiler can work with, but that's specific to the compiler, and
> presumably the compiler knows how to do it.

I'd prefer not to have conversion at all than rely on an
compiler-specific behavior.

> Agreed... though I'm less convinced that I was originally that this
> should even be in the domain of the preprocessor. I do agree however it
> should be __pragma-like rather than #pragma like (unless it supports both=
).

Or may be a part of template language. I hope C++ will have a simple,
powerful and readable compile time programming one day, which will allow
one to load a blob and arbitrarily process it in compile time with just
few lines of code. But that would be a different language, ((C++)++)++,
I guess.

> I beg to differ; many, if not most, GUI applications I have written or
> worked on have resources.

Most of GUI frameworks offer resource building tool, I think, and do
resource management much better then you would be able to do by hand
with that pragmas. How would you implement a similar feature:

    QFile file(QString(":/translation/%0.qm").arg(language))

which extracts from built-in resources file with name not known at
compile time?

=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.

--=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 20 February 2015 at 15:54, Pavel Kretov <firegurafiku@gmail.com> wrote:
> If you read my answer again, you'll find out I was talking about
> *shaders* and *firmware* blobs. As for images my statement is obviously
> not true. I hope, you're not going to blob-include XPM image files? :)

Uhh... why not? :)

--

---
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 02/20/2015 06:05 AM, Matthew Fioravante wrote:
> Another alternative could be to just use string literal prefixes and=20
> suffixes.
>=20
> __INCLUDE_FILE(X"file.txt"Y); //file.txt contains the text "file"
> X"\x66\x69\x6C\x65"Y; //Prefix and suffix applied to the resulting string=
=20
> literal

Or another option:

    char text_data[] =3D { __INCLUDE_FILE("file1.txt", 0 };
    uint8_t bin_data[] =3D {
                         0x01, 0x02, 0x03,
                         __INCLUDE_FILE("file1.bin"),
                         __INCLUDE_FILE("file2.bin"), }

where __INCLUDE_FILES expands to array initialization list *without*
brackets (and the trailing comma). This way both concatenation and
null-termination can be handled with a single inclusion macro.

Moreover, we cannot use string literals for binary inclusion as
their maximum length is limited by the standard (AFAIR).

=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.

--=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 2015-02-20 08:54, Pavel Kretov wrote:
>> You mean like... https://www.opengl.org/wiki/GLAPI/glShaderSource ?
>>
>> Shader compilation (at least every time *I've* ever dealt with GLSL)
>> happens *at run time*. Ergo, your statement is false, unless you define
>> "external compiler" as "the OpenGL library (that you are using anyway)".
>
> Unfortunately, I have no experience with GLSL (my fault, I think I
> should),

Bleh, yes... portability! :-D OpenGL is portable, DirectX... much less
so. (Well, except to XBox I guess.)

> I hope, you're not going to blob-include XPM image files? :)

Me too :-). (Usually .png's in my experience. Maybe .jpg's. The most
common embedded resources for projects I've worked on are interface
icons and sometimes other interface graphics e.g. splash screens, logos
for 'about' dialogs... Usually these are PNG, both because lossy
compression for something that's as small as 16x16 is bad, and because
the images frequently have non-trivial alpha channels.)

(@Ville, because they are a *textual* format that is much larger than a
directly-usable, uncompressed in-memory format :-). I mean, you *could*,
but eew...)

>> There may or may not be a conversion of file contents to something that
>> the compiler can work with, but that's specific to the compiler, and
>> presumably the compiler knows how to do it.
>
> I'd prefer not to have conversion at all than rely on an
> compiler-specific behavior.

What I meant there was more that the input binary blob should result in
an identical binary blob in the produced object file... which *may*
require the compiler to do some transformations for the sake of its
internal representation, but that should be transparent to the user.
(And that such translation would naturally be compiler-specific, since
compilers' internal data structures are of course not standardized.)

>> I beg to differ; many, if not most, GUI applications I have written or
>> worked on have resources.
>
> Most of GUI frameworks offer resource building tool, I think, and do
> resource management much better then you would be able to do by hand
> with that pragmas. How would you implement a similar feature:
>
>     QFile file(QString(":/translation/%0.qm").arg(language))
>
> which extracts from built-in resources file with name not known at
> compile time?

....much as it is implemented right now; have a 'resources.cpp' that uses
__load (or whatever) to load the resource into a char[], and then put a
reference to that into another global structure which contains the
resource names as strings. You would probably still have a code
generator for this, but it would be *much* simpler... and you *could*
readily write a similar resource loader source file by hand.

(Note: Qt's resources actually end up in one VERY LARGE blob. For Qt to
make use of this feature, it would probably be useful to change that to
a proper struct, especially as the current mechanism for encoding the
size would not work trivially. Even with rcc, however, this could be
useful; rcc would convert the .qrc to a resource .cpp with appropriate
load statements. Compiling the .cpp would then depend on the contents of
the resource files, while generating the .cpp would depend only on the
..qrc. This would be an improvement over things currently where
generating the .cpp depends on the resource files themselves. For that
matter, it would become much less important to generate the .cpp from
the .qrc as part of the build... you could do it by hand... conceivably
you could even just hand-write the thing.)

--
Matthew

--

---
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 2015-02-19 21:54, Matthew Fioravante wrote:
> On Thursday, February 19, 2015 at 7:04:53 PM UTC-5, Matthew Woehlke wrote:
>> On 2015-02-19 17:42, Matthew Fioravante wrote:
>>> One major issue I can think of regarding differentiating text
>>> from binary data which is null termination. When we import a text
>>> blob, we probably would like to have a null terminator added at
>>> the end so that the text can be used with legacy C api's. GPU
>>> shaders in OpenGL would require this.
>>
>> Hmm... good point. I was sort of assuming the presence of a null
>> terminator, but you're right that for "pure" binary data (say, image
>> files) this could be undesirable.
>
> One problem with null termination is that we need to be told the intended
> character type of the data (char, char16_t, char32_t, wchar_t) in order to
> know how many bytes to reserve for the null terminator and the type of the
> resulting string literal expression generated by the macro.

Doesn't this only apply to string literals? If 'pasting' as a list of
char literals ("'h','e','l','l','o',0"), the terminator is just '0', and
the compiler will expand that to fill the element, same as every other
element of the array.

For string literals, it's probably better for the width prefix to be
part of the expansion... although considering this opens the door to
endian conversion questions, my inclination is to only support char
const* literals, at least as a first pass.

>> That being the case, this may be a
>> good way to handle line endings also.
>
> What if the user wants null termination but doesn't want line ending
> processing?
>
> Maybe line endings, endian swapping, [...]

That'd be fine with me. I could also live without line ending
conversion, just saying that if you want to include text data, the
resource file must already have UNIX line endings. (It helps that I hate
Windows :-) and have strictly limited sympathy for its assorted
obnoxious idiosyncrasies.)

> The text routine needs type information to correctly allocate the null.
>
> constexpr auto data = __INCLUDE_BIN("some_file.bin");

....gives a decltype({0xff,0}), i.e. *a std::initializer_list*.

Now... at this point I'm strongly inclined to this, instead:

  // std::initializer_list, not terminated
  constexpr auto list = {__INCLUDE_LIST("some_file.bin")};
  // char[], not terminated
  constexpr char[] data = {__INCLUDE_LIST("some_file.bin")};
  // char[], terminated :-)
  constexpr char[] str = {__INCLUDE_LIST("some_file.bin"), 0};

(This brings up an interesting point; should we state that
__INCLUDE_LIST of an empty file followed by a ',' will remove the ',' a
la MSVC's variadic macros? It seems desirable... or we could just not
support this case where the file is empty.)

> constexpr auto text = __INCLUDE_TEXT(char,"some_file.txt");

....gives a decltype("string literal").

> The binary routine could also use type information which can be useful if
> you want signed of unsigned bytes:
>
> constexpr auto data = __INCLUDE_BIN(uint8_t,"some_file.bin");

No; it should give an initializer_list (or better, token list, as
explained above); the LHS type determines the concrete type. Yes, this
means you can't assign it to 'auto' (unless you *want* the initializer
list), but you *do* want the initializer list to be able to pass it
directly to class constructors.

>  __INCLUDE_TEXT should expand to a string literal.
>
> The reason for this is that now we can paste string literals together,
> which comes for free from the behavior of string literals.

Ooh, good point! Bonus! :-)

> The only compatible way to implement __INCLUDE_BIN() is to replace the
> macro with an array initialization.
>
> This would mean you can't paste together multiple __INCLUDE_BIN()
> expressions like you can with __INCLUDE_TEXT().

This would be another reason to have __INCLUDE_LIST instead.

--
Matthew

--

---
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 2015-02-20 09:38, Pavel Kretov wrote:
> Moreover, we cannot use string literals for binary inclusion as
> their maximum length is limited by the standard (AFAIR).

Really? (Citation needed?)

In the bad old days of early C compilers, some compilers had a limit on
the length of string literals that were accepted. Newer compilers
relaxed this.

I would expect that the standard sets a *lower* bound on the maximum
size of a string literal. I can't think why it would set an *upper*
bound (other than e.g. numeric_limits<size_t>::max()... and you *really*
shouldn't be embedding anything larger than that, or even a fraction
that large for that matter).

--
Matthew

--

---
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 20 February 2015 at 18:26, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> On 2015-02-20 09:38, Pavel Kretov wrote:
>> Moreover, we cannot use string literals for binary inclusion as
>> their maximum length is limited by the standard (AFAIR).
>
> Really? (Citation needed?)
>
> In the bad old days of early C compilers, some compilers had a limit on
> the length of string literals that were accepted. Newer compilers
> relaxed this.
>
> I would expect that the standard sets a *lower* bound on the maximum
> size of a string literal. I can't think why it would set an *upper*
> bound (other than e.g. numeric_limits<size_t>::max()... and you *really*
> shouldn't be embedding anything larger than that, or even a fraction
> that large for that matter).


A citation thou desire, a citation ye shall receive:
[implimits]/2: "The bracketed number following each quantity is recommended
as the minimum for that quantity. However, these quantities are only guidelines
and do not determine compliance."

In other words, the standard specifies neither a lower nor an upper
limit; it gives
a _recommendation_ for a "lower bound", and for string literals that
recommendation is
"Characters in a string literal (after concatenation) [65 536]."

--

---
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 2015-02-20 11:36, Ville Voutilainen wrote:
> On 20 February 2015 at 18:26, Matthew Woehlke wrote:
>> On 2015-02-20 09:38, Pavel Kretov wrote:
>>> Moreover, we cannot use string literals for binary inclusion as
>>> their maximum length is limited by the standard (AFAIR).
>>
>> Really? (Citation needed?)
>>
>> In the bad old days of early C compilers, some compilers had a limit on
>> the length of string literals that were accepted. Newer compilers
>> relaxed this.
>>
>> I would expect that the standard sets a *lower* bound on the maximum
>> size of a string literal. I can't think why it would set an *upper*
>> bound (other than e.g. numeric_limits<size_t>::max()... and you *really*
>> shouldn't be embedding anything larger than that, or even a fraction
>> that large for that matter).
>
> A citation thou desire, a citation ye shall receive:
> [implimits]/2: "The bracketed number following each quantity is recommended
> as the minimum for that quantity. However, these quantities are only guidelines
> and do not determine compliance."
>
> In other words, the standard specifies neither a lower nor an upper
> limit; it gives
> a _recommendation_ for a "lower bound", and for string literals that
> recommendation is
> "Characters in a string literal (after concatenation) [65 536]."

Thanks, Ville! That matches my recollection from Ye Olde Dayes of C and
is what I would expect; there is *not* a legislated maximum length of a
string literal.

It may be that for this feature, some compilers would be... encouraged
to support longer literals than they do currently. Critically, however,
the standard does *not* mandate that string literals longer than some
length must be rejected. So I don't think there is a problem here.

--
Matthew

--

---
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_552_1603651079.1424452376202
Content-Type: multipart/alternative;
 boundary="----=_Part_553_1643914903.1424452376202"

------=_Part_553_1643914903.1424452376202
Content-Type: text/plain; charset=UTF-8



On Friday, February 20, 2015 at 11:22:01 AM UTC-5, Matthew Woehlke wrote:
>
> On 2015-02-19 21:54, Matthew Fioravante wrote:
> > On Thursday, February 19, 2015 at 7:04:53 PM UTC-5, Matthew Woehlke
> wrote:
> >> On 2015-02-19 17:42, Matthew Fioravante wrote:
> >>> One major issue I can think of regarding differentiating text
> >>> from binary data which is null termination. When we import a text
> >>> blob, we probably would like to have a null terminator added at
> >>> the end so that the text can be used with legacy C api's. GPU
> >>> shaders in OpenGL would require this.
> >>
> >> Hmm... good point. I was sort of assuming the presence of a null
> >> terminator, but you're right that for "pure" binary data (say, image
> >> files) this could be undesirable.
> >
> > One problem with null termination is that we need to be told the
> intended
> > character type of the data (char, char16_t, char32_t, wchar_t) in order
> to
> > know how many bytes to reserve for the null terminator and the type of
> the
> > resulting string literal expression generated by the macro.
>
> Doesn't this only apply to string literals? If 'pasting' as a list of
> char literals ("'h','e','l','l','o',0"), the terminator is just '0', and
> the compiler will expand that to fill the element, same as every other
> element of the array.
>

This not possible to use directly with larger N byte character types
without some logic to construct each character with N initializers. The
library could be used to coerce the byte stream into a stream of char32_t,
with endian conversion, byte order mark search, etc..

The big benefit of leveraging string literals is that you can concatenate
sting literals in the source code with included text data from a file
easily using an already existing engine in the standard.



>
> For string literals, it's probably better for the width prefix to be
> part of the expansion... although considering this opens the door to
> endian conversion questions, my inclination is to only support char
> const* literals, at least as a first pass.
>
> >> That being the case, this may be a
> >> good way to handle line endings also.
> >
> > What if the user wants null termination but doesn't want line ending
> > processing?
> >
> > Maybe line endings, endian swapping, [...]
>
> That'd be fine with me. I could also live without line ending
> conversion, just saying that if you want to include text data, the
> resource file must already have UNIX line endings. (It helps that I hate
> Windows :-) and have strictly limited sympathy for its assorted
> obnoxious idiosyncrasies.)
>

Compatibility is a good reason for choping line endings, but maybe this
processing is still better done in the library.


>
> > The text routine needs type information to correctly allocate the null.
> >
> > constexpr auto data = __INCLUDE_BIN("some_file.bin");
>
> ...gives a decltype({0xff,0}), i.e. *a std::initializer_list*.
>
> Now... at this point I'm strongly inclined to this, instead:
>
>   // std::initializer_list, not terminated
>   constexpr auto list = {__INCLUDE_LIST("some_file.bin")};
>   // char[], not terminated
>   constexpr char[] data = {__INCLUDE_LIST("some_file.bin")};
>   // char[], terminated :-)
>   constexpr char[] str = {__INCLUDE_LIST("some_file.bin"), 0};
>

Thats a nice way to handle the optionality of adding a null terminator. It
doesn't work well for string literals though. You cannot concatenate like
this: __INCLUDE_LIST("somefile.txt") U("Unicode footer");



>
> (This brings up an interesting point; should we state that
> __INCLUDE_LIST of an empty file followed by a ',' will remove the ',' a
> la MSVC's variadic macros? It seems desirable... or we could just not
> support this case where the file is empty.)
>

I would treat an empty file like an empty string literal, which means it
becomes a no-op. So if we used your approach that means getting rid of the
comma.


>
> > constexpr auto text = __INCLUDE_TEXT(char,"some_file.txt");
>
> ...gives a decltype("string literal").
>
> > The binary routine could also use type information which can be useful
> if
> > you want signed of unsigned bytes:
> >
> > constexpr auto data = __INCLUDE_BIN(uint8_t,"some_file.bin");
>
> No; it should give an initializer_list (or better, token list, as
> explained above); the LHS type determines the concrete type. Yes, this
> means you can't assign it to 'auto' (unless you *want* the initializer
> list), but you *do* want the initializer list to be able to pass it
> directly to class constructors.
>
> >  __INCLUDE_TEXT should expand to a string literal.
> >
> > The reason for this is that now we can paste string literals together,
> > which comes for free from the behavior of string literals.
>
> Ooh, good point! Bonus! :-)
>
> > The only compatible way to implement __INCLUDE_BIN() is to replace the
> > macro with an array initialization.
> >
> > This would mean you can't paste together multiple __INCLUDE_BIN()
> > expressions like you can with __INCLUDE_TEXT().
>
> This would be another reason to have __INCLUDE_LIST instead.
>
> --
> Matthew
>
>
For binary files, we could just use the library again. This would further
simplify the include macro.

__INCLUDE_FILE("some_file.bin");
"\x01\x02\x03\x04...."; //<- expands to this, which is null terminated
__INCLUDE_FILE(u"some_file.bin");
u"\x0102\x0304...."; //<- expands to this, which is null terminated
__INCLUDE_FILE(U"some_file.bin");
U"\x01020304...."; //<- expands to this, which is null terminated
__INCLUDE_FILE(L"some_file.bin");
L"\x0102\x0304...."; //<- expands to this (example assuming sizeof(wchar_t)
== 16), which is null terminated

template <typename T, size_t N>
constexpr std::array<T,N-1> binary(const char(&lit)[N]) { return { lit.begin
(), lit.end()-1 }; }

auto fw = binary(__INCLUDE_FILE("firmware.bin"));


The possibilities for this feature with compile time programming to mutate
the data at compile time is very interesting.


--

---
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_553_1643914903.1424452376202
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, February 20, 2015 at 11:22:01 AM UTC-5,=
 Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015=
-02-19 21:54, Matthew Fioravante wrote:
<br>&gt; On Thursday, February 19, 2015 at 7:04:53 PM UTC-5, Matthew Woehlk=
e wrote:
<br>&gt;&gt; On 2015-02-19 17:42, Matthew Fioravante wrote:=20
<br>&gt;&gt;&gt; One major issue I can think of regarding differentiating t=
ext
<br>&gt;&gt;&gt; from binary data which is null termination. When we import=
 a text
<br>&gt;&gt;&gt; blob, we probably would like to have a null terminator add=
ed at
<br>&gt;&gt;&gt; the end so that the text can be used with legacy C api's. =
GPU
<br>&gt;&gt;&gt; shaders in OpenGL would require this.
<br>&gt;&gt;
<br>&gt;&gt; Hmm... good point. I was sort of assuming the presence of a nu=
ll=20
<br>&gt;&gt; terminator, but you're right that for "pure" binary data (say,=
 image=20
<br>&gt;&gt; files) this could be undesirable.=20
<br>&gt;=20
<br>&gt; One problem with null termination is that we need to be told the i=
ntended=20
<br>&gt; character type of the data (char, char16_t, char32_t, wchar_t) in =
order to=20
<br>&gt; know how many bytes to reserve for the null terminator and the typ=
e of the=20
<br>&gt; resulting string literal expression generated by the macro.
<br>
<br>Doesn't this only apply to string literals? If 'pasting' as a list of
<br>char literals ("'h','e','l','l','o',0"), the terminator is just '0', an=
d
<br>the compiler will expand that to fill the element, same as every other
<br>element of the array.
<br></blockquote><div><br></div><div>This not possible to use directly with=
 larger N byte character types without some logic to construct each charact=
er with N initializers. The library could be used to coerce the byte stream=
 into a stream of char32_t, with endian conversion, byte order mark search,=
 etc..</div><div><br></div><div>The big benefit of leveraging string litera=
ls is that you can concatenate sting literals in the source code with inclu=
ded text data from a file easily using an already existing engine in the st=
andard.</div><div><br></div><div>&nbsp;</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">
<br>For string literals, it's probably better for the width prefix to be
<br>part of the expansion... although considering this opens the door to
<br>endian conversion questions, my inclination is to only support char
<br>const* literals, at least as a first pass.
<br>
<br>&gt;&gt; That being the case, this may be a=20
<br>&gt;&gt; good way to handle line endings also.=20
<br>&gt;=20
<br>&gt; What if the user wants null termination but doesn't want line endi=
ng=20
<br>&gt; processing?
<br>&gt;=20
<br>&gt; Maybe line endings, endian swapping, [...]
<br>
<br>That'd be fine with me. I could also live without line ending
<br>conversion, just saying that if you want to include text data, the
<br>resource file must already have UNIX line endings. (It helps that I hat=
e
<br>Windows :-) and have strictly limited sympathy for its assorted
<br>obnoxious idiosyncrasies.)
<br></blockquote><div><br></div><div>Compatibility is a good reason for cho=
ping line endings, but maybe this processing is still better done in the li=
brary.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; The text routine needs type information to correctly allocate the =
null.
<br>&gt;=20
<br>&gt; constexpr auto data =3D __INCLUDE_BIN("some_file.bin")<wbr>;
<br>
<br>...gives a decltype({0xff,0}), i.e. *a std::initializer_list*.
<br>
<br>Now... at this point I'm strongly inclined to this, instead:
<br>
<br>&nbsp; // std::initializer_list, not terminated
<br>&nbsp; constexpr auto list =3D {__INCLUDE_LIST("some_file.<wbr>bin")};
<br>&nbsp; // char[], not terminated
<br>&nbsp; constexpr char[] data =3D {__INCLUDE_LIST("some_file.<wbr>bin")}=
;
<br>&nbsp; // char[], terminated :-)
<br>&nbsp; constexpr char[] str =3D {__INCLUDE_LIST("some_file.<wbr>bin"), =
0};
<br></blockquote><div><br></div><div>Thats a nice way to handle the optiona=
lity of adding a null terminator. It doesn't work well for string literals =
though. You cannot concatenate like this: __INCLUDE_LIST("somefile.txt") U(=
"Unicode footer");</div><div><br></div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>(This brings up an interesting point; should we state that
<br>__INCLUDE_LIST of an empty file followed by a ',' will remove the ',' a
<br>la MSVC's variadic macros? It seems desirable... or we could just not
<br>support this case where the file is empty.)
<br></blockquote><div><br></div><div>I would treat an empty file like an em=
pty string literal, which means it becomes a no-op. So if we used your appr=
oach that means getting rid of the comma.&nbsp;</div><div>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; constexpr auto text =3D __INCLUDE_TEXT(char,"some_<wbr>file.txt");
<br>
<br>...gives a decltype("string literal").
<br>
<br>&gt; The binary routine could also use type information which can be us=
eful if=20
<br>&gt; you want signed of unsigned bytes:
<br>&gt;=20
<br>&gt; constexpr auto data =3D __INCLUDE_BIN(uint8_t,"some_<wbr>file.bin"=
);
<br>
<br>No; it should give an initializer_list (or better, token list, as
<br>explained above); the LHS type determines the concrete type. Yes, this
<br>means you can't assign it to 'auto' (unless you *want* the initializer
<br>list), but you *do* want the initializer list to be able to pass it
<br>directly to class constructors.
<br>
<br>&gt; &nbsp;__INCLUDE_TEXT should expand to a string literal.
<br>&gt;=20
<br>&gt; The reason for this is that now we can paste string literals toget=
her,=20
<br>&gt; which comes for free from the behavior of string literals.
<br>
<br>Ooh, good point! Bonus! :-)
<br>
<br>&gt; The only compatible way to implement __INCLUDE_BIN() is to replace=
 the=20
<br>&gt; macro with an array initialization.
<br>&gt;=20
<br>&gt; This would mean you can't paste together multiple __INCLUDE_BIN()=
=20
<br>&gt; expressions like you can with __INCLUDE_TEXT().
<br>
<br>This would be another reason to have __INCLUDE_LIST instead.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div><div>For binary files, we could just use th=
e library again. This would further simplify the include macro.</div><div><=
br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187=
, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">__INCLUDE_FILE</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"some_file.bin"</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">"\x01\x02\x03\x04...."</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//&lt;- expands to this, which is null terminated</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>__INCLUD=
E_FILE</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">u</span><span=
 style=3D"color: #080;" class=3D"styled-by-prettify">"some_file.bin"</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>u</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"\x0102\x0304...."</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">//&lt;- expands to this, which is nul=
l terminated</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>__INCLUDE_FILE</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>U</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"some_fi=
le.bin"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>U</span=
><span style=3D"color: #080;" class=3D"styled-by-prettify">"\x01020304...."=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//&lt;- expands to this, whi=
ch is null terminated</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>__INCLUDE_FILE</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><font color=3D"#000000"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">L</span></font><span style=3D"color: #080=
;" class=3D"styled-by-prettify">"some_file.bin"</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>L</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"\x0102\x0304...."</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">//&lt;- expands to this (example assuming sizeof(wchar_t) =
=3D=3D 16), which is null terminated</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><f=
ont color=3D"#000088"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">size_t N</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></font><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nstexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">array</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">N</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">-</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bin=
ary</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(&amp;</span><font color=3D"#00000=
0"><span style=3D"color: #000;" class=3D"styled-by-prettify">lit</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">N</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">])</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> lit</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">begin</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> lit</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">end</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">()-</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>1</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></font><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> fw </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> binary</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">__IN=
CLUDE_FILE</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"firmware=
..bin"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></sp=
an></div></code></div><br>The possibilities for this feature with compile t=
ime programming to mutate the data at compile time is very interesting.&nbs=
p;</div><div>&nbsp;</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_553_1643914903.1424452376202--
------=_Part_552_1603651079.1424452376202--

.

On 2015-02-20 12:12, Matthew Fioravante wrote:
> On Friday, February 20, 2015 at 11:22:01 AM UTC-5, Matthew Woehlke wrote:
>> On 2015-02-19 21:54, Matthew Fioravante wrote:
>>> One problem with null termination is that we need to be told the
>>> intended character type of the data (char, char16_t, char32_t,
>>> wchar_t) in order to know how many bytes to reserve for the null
>>> terminator and the type of the resulting string literal
>>> expression generated by the macro.
>>
>> Doesn't this only apply to string literals? If 'pasting' as a list of
>> char literals ("'h','e','l','l','o',0"), the terminator is just '0', and
>> the compiler will expand that to fill the element, same as every other
>> element of the array.
>
> This not possible to use directly with larger N byte character types
> without some logic to construct each character with N initializers. The
> library could be used to coerce the byte stream into a stream of char32_t,
> with endian conversion, byte order mark search, etc..

I'm not/less worried about that case. As has been said repeatedly, get
the byte-wise case working first. I'm not even wholly convinced that
list-of-wider-types should be supported *at all* (aside from promotion
from char... not sure what would be a use case for that, but the
language already supports it).

> The big benefit of leveraging string literals is that you can concatenate
> sting literals in the source code with included text data from a file
> easily using an already existing engine in the standard.

You can do the same to a char-literal list (assuming a raw list, i.e.
not surrounded by {}'s).

>> (This brings up an interesting point; should we state that
>> __INCLUDE_LIST of an empty file followed by a ',' will remove the ',' a
>> la MSVC's variadic macros? It seems desirable... or we could just not
>> support this case where the file is empty.)
>
> I would treat an empty file like an empty string literal, which means it
> becomes a no-op. So if we used your approach that means getting rid of the
> comma.

Yes, for string literals, it's trivial :-). I would also prefer to
implicitly drop the comma, but I can imagine some people finding that
objectionable. I think it would be okay if this just produces an error
if the input file is empty; how often is that going to happen, anyway?
(It would have to be a case where you don't know beforehand that the
file will be empty... otherwise why are you loading it?)

> For binary files, we could just use the library again. This would further
> simplify the include macro.
>
> __INCLUDE_FILE("some_file.bin");
> "\x01\x02\x03\x04...."; //<- expands to this, which is null terminated
> __INCLUDE_FILE(u"some_file.bin");
> u"\x0102\x0304...."; //<- expands to this, which is null terminated
> __INCLUDE_FILE(U"some_file.bin");
> U"\x01020304...."; //<- expands to this, which is null terminated
> __INCLUDE_FILE(L"some_file.bin");
> L"\x0102\x0304...."; //<- expands to this (example assuming sizeof(wchar_t)
> == 16), which is null terminated

Above point about getting the simple case right first, what bothers me
about that syntax is that it looks like the file name itself is being
given as a wide string. I would strongly prefer that it be a separate
argument. (In which case I would have some preference for using a type
name rather than a suffix, though I would be okay with either.)

--
Matthew

--

---
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_571_137963941.1424454714770
Content-Type: multipart/alternative;
 boundary="----=_Part_572_1625101274.1424454714770"

------=_Part_572_1625101274.1424454714770
Content-Type: text/plain; charset=UTF-8



On Friday, February 20, 2015 at 12:27:58 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-02-20 12:12, Matthew Fioravante wrote:
> > On Friday, February 20, 2015 at 11:22:01 AM UTC-5, Matthew Woehlke
> wrote:
> >> On 2015-02-19 21:54, Matthew Fioravante wrote:
> >>> One problem with null termination is that we need to be told the
> >>> intended character type of the data (char, char16_t, char32_t,
> >>> wchar_t) in order to know how many bytes to reserve for the null
> >>> terminator and the type of the resulting string literal
> >>> expression generated by the macro.
> >>
> >> Doesn't this only apply to string literals? If 'pasting' as a list of
> >> char literals ("'h','e','l','l','o',0"), the terminator is just '0',
> and
> >> the compiler will expand that to fill the element, same as every other
> >> element of the array.
> >
> > This not possible to use directly with larger N byte character types
> > without some logic to construct each character with N initializers. The
> > library could be used to coerce the byte stream into a stream of
> char32_t,
> > with endian conversion, byte order mark search, etc..
>
> I'm not/less worried about that case. As has been said repeatedly, get
> the byte-wise case working first. I'm not even wholly convinced that
> list-of-wider-types should be supported *at all* (aside from promotion
> from char... not sure what would be a use case for that, but the
> language already supports it).
>
> > The big benefit of leveraging string literals is that you can
> concatenate
> > sting literals in the source code with included text data from a file
> > easily using an already existing engine in the standard.
>
> You can do the same to a char-literal list (assuming a raw list, i.e.
> not surrounded by {}'s).
>

Its very clumsy writing 'l','i','k','e',' ','t','h','i','s'. It would be
nice if you could concatenate the result with a string literal.


>
> >> (This brings up an interesting point; should we state that
> >> __INCLUDE_LIST of an empty file followed by a ',' will remove the ',' a
> >> la MSVC's variadic macros? It seems desirable... or we could just not
> >> support this case where the file is empty.)
> >
> > I would treat an empty file like an empty string literal, which means it
> > becomes a no-op. So if we used your approach that means getting rid of
> the
> > comma.
>
> Yes, for string literals, it's trivial :-). I would also prefer to
> implicitly drop the comma, but I can imagine some people finding that
> objectionable.


When is leaving an extra comma ever a good thing? I would be aggressive and
push to have it removed to make this feature more useful.



> I think it would be okay if this just produces an error
> if the input file is empty; how often is that going to happen, anyway?
> (It would have to be a case where you don't know beforehand that the
> file will be empty... otherwise why are you loading it?)
>

Opening an empty file seems perfectly legitimate to me. Making it an error
would be restrictive for no good reason. Maybe in development you just have
a placeholder. Or you are including several files together and one of them
is empty for now but will be created later. You can include an empty header
file, so why not include an empty resource.


> > For binary files, we could just use the library again. This would
> further
> > simplify the include macro.
> >
> > __INCLUDE_FILE("some_file.bin");
> > "\x01\x02\x03\x04...."; //<- expands to this, which is null terminated
> > __INCLUDE_FILE(u"some_file.bin");
> > u"\x0102\x0304...."; //<- expands to this, which is null terminated
> > __INCLUDE_FILE(U"some_file.bin");
> > U"\x01020304...."; //<- expands to this, which is null terminated
> > __INCLUDE_FILE(L"some_file.bin");
> > L"\x0102\x0304...."; //<- expands to this (example assuming
> sizeof(wchar_t)
> > == 16), which is null terminated
>
> Above point about getting the simple case right first, what bothers me
> about that syntax is that it looks like the file name itself is being
> given as a wide string. I would strongly prefer that it be a separate
> argument. (In which case I would have some preference for using a type
> name rather than a suffix, though I would be okay with either.)
>

The only information we really need is the size of the type.
If the result macro expands to a string literal, than it needs to be given
a prefix to mark the type of the literal. Using the prefix on the filename
tells us exactly what the macro expansion is going to look like, even
though I agree that it does look like we're specifying the encoding of the
filename. These file names would follow the same rules for #include
filenames.

The prefix or type could be a separate argument:

__INCLUDE_FILE("some_file.bin", char32_t);
__INCLUDE_FILE(U, "some_file.bin");


If the result macro expands into a list, then the type information is not
really needed at all because we can use library components to coerce the
initializer list of bytes into a type if needed.


> --
> Matthew
>
>

--

---
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_572_1625101274.1424454714770
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, February 20, 2015 at 12:27:58 PM UTC-5,=
 Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015=
-02-20 12:12, Matthew Fioravante wrote:
<br>&gt; On Friday, February 20, 2015 at 11:22:01 AM UTC-5, Matthew Woehlke=
 wrote:
<br>&gt;&gt; On 2015-02-19 21:54, Matthew Fioravante wrote:=20
<br>&gt;&gt;&gt; One problem with null termination is that we need to be to=
ld the=20
<br>&gt;&gt;&gt; intended character type of the data (char, char16_t, char3=
2_t,
<br>&gt;&gt;&gt; wchar_t) in order to know how many bytes to reserve for th=
e null
<br>&gt;&gt;&gt; terminator and the type of the resulting string literal
<br>&gt;&gt;&gt; expression generated by the macro.
<br>&gt;&gt;
<br>&gt;&gt; Doesn't this only apply to string literals? If 'pasting' as a =
list of=20
<br>&gt;&gt; char literals ("'h','e','l','l','o',0"), the terminator is jus=
t '0', and=20
<br>&gt;&gt; the compiler will expand that to fill the element, same as eve=
ry other=20
<br>&gt;&gt; element of the array.=20
<br>&gt;=20
<br>&gt; This not possible to use directly with larger N byte character typ=
es=20
<br>&gt; without some logic to construct each character with N initializers=
.. The=20
<br>&gt; library could be used to coerce the byte stream into a stream of c=
har32_t,=20
<br>&gt; with endian conversion, byte order mark search, etc..
<br>
<br>I'm not/less worried about that case. As has been said repeatedly, get
<br>the byte-wise case working first. I'm not even wholly convinced that
<br>list-of-wider-types should be supported *at all* (aside from promotion
<br>from char... not sure what would be a use case for that, but the
<br>language already supports it).
<br>
<br>&gt; The big benefit of leveraging string literals is that you can conc=
atenate=20
<br>&gt; sting literals in the source code with included text data from a f=
ile=20
<br>&gt; easily using an already existing engine in the standard.
<br>
<br>You can do the same to a char-literal list (assuming a raw list, i.e.
<br>not surrounded by {}'s).
<br></blockquote><div><br></div><div>Its very clumsy writing 'l','i','k','e=
',' ','t','h','i','s'. It would be nice if you could concatenate the result=
 with a string literal.</div><div>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
<br>&gt;&gt; (This brings up an interesting point; should we state that=20
<br>&gt;&gt; __INCLUDE_LIST of an empty file followed by a ',' will remove =
the ',' a=20
<br>&gt;&gt; la MSVC's variadic macros? It seems desirable... or we could j=
ust not=20
<br>&gt;&gt; support this case where the file is empty.)=20
<br>&gt;=20
<br>&gt; I would treat an empty file like an empty string literal, which me=
ans it=20
<br>&gt; becomes a no-op. So if we used your approach that means getting ri=
d of the=20
<br>&gt; comma.=20
<br>
<br>Yes, for string literals, it's trivial :-). I would also prefer to
<br>implicitly drop the comma, but I can imagine some people finding that
<br>objectionable.</blockquote><div><br></div><div>When is leaving an extra=
 comma ever a good thing? I would be aggressive and push to have it removed=
 to make this feature more useful.</div><div><br></div><div>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"> I think it would be okay if this=
 just produces an error
<br>if the input file is empty; how often is that going to happen, anyway?
<br>(It would have to be a case where you don't know beforehand that the
<br>file will be empty... otherwise why are you loading it?)
<br></blockquote><div><br></div><div>Opening an empty file seems perfectly =
legitimate to me. Making it an error would be restrictive for no good reaso=
n. Maybe in development you just have a placeholder. Or you are including s=
everal files together and one of them is empty for now but will be created =
later. You can include an empty header file, so why not include an empty re=
source.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; For binary files, we could just use the library again. This would =
further=20
<br>&gt; simplify the include macro.
<br>&gt;=20
<br>&gt; __INCLUDE_FILE("some_file.bin"<wbr>);
<br>&gt; "\x01\x02\x03\x04...."; //&lt;- expands to this, which is null ter=
minated
<br>&gt; __INCLUDE_FILE(u"some_file.<wbr>bin");
<br>&gt; u"\x0102\x0304...."; //&lt;- expands to this, which is null termin=
ated
<br>&gt; __INCLUDE_FILE(U"some_file.<wbr>bin");
<br>&gt; U"\x01020304...."; //&lt;- expands to this, which is null terminat=
ed
<br>&gt; __INCLUDE_FILE(L"some_file.<wbr>bin");
<br>&gt; L"\x0102\x0304...."; //&lt;- expands to this (example assuming siz=
eof(wchar_t)=20
<br>&gt; =3D=3D 16), which is null terminated
<br>
<br>Above point about getting the simple case right first, what bothers me
<br>about that syntax is that it looks like the file name itself is being
<br>given as a wide string. I would strongly prefer that it be a separate
<br>argument. (In which case I would have some preference for using a type
<br>name rather than a suffix, though I would be okay with either.)
<br></blockquote><div><br></div><div>The only information we really need is=
 the size of the type.&nbsp;</div><div>If the result macro expands to a str=
ing literal, than it needs to be given a prefix to mark the type of the lit=
eral. Using the prefix on the filename tells us exactly what the macro expa=
nsion is going to look like, even though I agree that it does look like we'=
re specifying the encoding of the filename. These file names would follow t=
he same rules for #include filenames.</div><div><br></div><div>The prefix o=
r type could be a separate argument:</div><div><br></div><div><div class=3D=
"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: bre=
ak-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color=
: #000;" class=3D"styled-by-prettify">__INCLUDE_FILE</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #08=
0;" class=3D"styled-by-prettify">"some_file.bin"</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> char32_t</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>__INCLUDE_FILE</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">U</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"some_fi=
le.bin"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span></font></div></code></div><br></div><div><br></div><div>If the result=
 macro expands into a list, then the type information is not really needed =
at all because we can use library components to coerce the initializer list=
 of bytes into a type if needed.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">
<br>--=20
<br>Matthew
<br>
<br></blockquote></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_572_1625101274.1424454714770--
------=_Part_571_137963941.1424454714770--

.

On 2015-02-20 12:51, Matthew Fioravante wrote:
> On Friday, February 20, 2015 at 12:27:58 PM UTC-5, Matthew Woehlke wrote:
>> On 2015-02-20 12:12, Matthew Fioravante wrote:
>>> On Friday, February 20, 2015 at 11:22:01 AM UTC-5, Matthew Woehlke wrote:
>>>> (This brings up an interesting point; should we state that
>>>> __INCLUDE_LIST of an empty file followed by a ',' will remove the ',' a
>>>> la MSVC's variadic macros? It seems desirable... or we could just not
>>>> support this case where the file is empty.)
>>>
>>> I would treat an empty file like an empty string literal, which means it
>>> becomes a no-op. So if we used your approach that means getting rid of
>>> the comma.
>>
>> Yes, for string literals, it's trivial :-). I would also prefer to
>> implicitly drop the comma, but I can imagine some people finding that
>> objectionable.
>
> When is leaving an extra comma ever a good thing? I would be aggressive and
> push to have it removed to make this feature more useful.

I mean that some people might object to the standard requiring such an
automagical feature. (At least I get that impression; otherwise, why
isn't it standard for ", __VA_ARGS__" to be transformed to empty if
__VA_ARGS__ is empty?)

Ack... and that's another point, *leading* commas need to be handled
also. IOW (given an empty file), all of these need to work:

  {0, __include_list("foo")} // {0}
  {__include_list("foo"), 0} // {0}
  {0, __include_list("foo"), 0} // {0, 0}

I'd prefer that this work, I'm just worried about how well it will be
accepted.

> Opening an empty file seems perfectly legitimate to me. Making it an error
> would be restrictive for no good reason.

To be clear: it's not an error in and of itself, it just breaks in e.g.
the above examples because you wind up with extra commas. Something like
'__include_list("/dev/null")' would always be valid and would always
produce an empty token sequence.

> If the result macro expands into a list, then the type information is not
> really needed at all because we can use library components to coerce the
> initializer list of bytes into a type if needed.

Right; if we support specifying a type, only the string literal flavor
needs that. (I still think we should support both.)

--
Matthew

--

---
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 Friday 20 February 2015 11:00:34 Matthew Woehlke wrote:
> (Note: Qt's resources actually end up in one VERY LARGE blob. For Qt to
> make use of this feature, it would probably be useful to change that to
> a proper struct, especially as the current mechanism for encoding the
> size would not work trivially. Even with rcc, however, this could be
> useful; rcc would convert the .qrc to a resource .cpp with appropriate
> load statements. Compiling the .cpp would then depend on the contents of
> the resource files, while generating the .cpp would depend only on the
> .qrc. This would be an improvement over things currently where
> generating the .cpp depends on the resource files themselves. For that
> matter, it would become much less important to generate the .cpp from
> the .qrc as part of the build... you could do it by hand... conceivably
> you could even just hand-write the thing.)

There's a two-pass mode for rcc now that binary-edits the .o file. That works
much better for large resource collections, but it doesn't play well with
compressed objects or LTO.

objcopy is another way of inserting binary data into object files.

--
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 Fri, Feb 20, 2015 at 01:34:20PM -0500, Matthew Woehlke wrote:
> On 2015-02-20 12:51, Matthew Fioravante wrote:
> > On Friday, February 20, 2015 at 12:27:58 PM UTC-5, Matthew Woehlke wrote:
> >> On 2015-02-20 12:12, Matthew Fioravante wrote:
> >>> On Friday, February 20, 2015 at 11:22:01 AM UTC-5, Matthew Woehlke wrote:
> >>>> (This brings up an interesting point; should we state that
> >>>> __INCLUDE_LIST of an empty file followed by a ',' will remove the ',' a
> >>>> la MSVC's variadic macros? It seems desirable... or we could just not
> >>>> support this case where the file is empty.)
> >>>
> >>> I would treat an empty file like an empty string literal, which means it
> >>> becomes a no-op. So if we used your approach that means getting rid of
> >>> the comma.
> >>
> >> Yes, for string literals, it's trivial :-). I would also prefer to
> >> implicitly drop the comma, but I can imagine some people finding that
> >> objectionable.
> >
> > When is leaving an extra comma ever a good thing? I would be aggressive and
> > push to have it removed to make this feature more useful.
>
> I mean that some people might object to the standard requiring such an
> automagical feature. (At least I get that impression; otherwise, why
> isn't it standard for ", __VA_ARGS__" to be transformed to empty if
> __VA_ARGS__ is empty?)
>
> Ack... and that's another point, *leading* commas need to be handled
> also. IOW (given an empty file), all of these need to work:
>
>   {0, __include_list("foo")} // {0}
>   {__include_list("foo"), 0} // {0}
>   {0, __include_list("foo"), 0} // {0, 0}

If __include_list expands to a number of "0xVALUE ," elements, with a trailing
comma then one could write { 0, __include_list("foo") } ,
{ __include_list("foo") 0 } and { 0, __include_list("foo") 0 } but the
problem is that

{ __include_list("foo") 0 }

is ugly. (remember that a trailing comma is allowed in a brace-initializer)

/MF

--

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

.

--Apple-Mail=_9F859D55-780B-4C42-8BB8-B4136492067F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9318, at 5:54 AM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> QResource also supports reading a resource directory directly from a file=
,=20
> instead of something registered inside the binary image (see=20
> QResource::registerResource).
>=20
> But David's description is more similar to QFileSelector.

My suggestion is to allow the implementation to decide to store a resource =
inside the binary or outside. The existence of similar (albeit manually-con=
trolled) functionality in Qt is evidence that it=E2=80=99s useful to refer =
to a resource without reference to its storage medium.

All this insistence on metaprogramming is bizarre. Many GUI apps pre-scale =
image resources for different resolutions. As mentioned, some like to valid=
ate OpenGL shaders. Is it somehow better to put Herculean effort into achie=
ving these tasks with C++ metaprogramming, instead of using ordinary tools =
with ordinary toolchains that exist today?

The goal is to allow portable libraries to include resource data. Portable =
specification of resource processing is not a part of this. Images will be =
scaled differently for different platforms=E2=80=99 various screen resoluti=
ons. Shaders will be validated against various platform-specific extensions=
 and bugs, if at all. A portable library should be able to include raw reso=
urce files, and simple named references to them. (There are semi-portable n=
aming conventions, like @4x.png for a high-resolution image. Libraries can =
use such resource mappings at their own peril, it=E2=80=99s not really the =
concern of the C++ standard.)

This thread is way off track. It=E2=80=99s a red flag to even be thinking a=
bout the notions of text encoding and string termination. Just don=E2=80=99=
t.

--=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/.

--Apple-Mail=_9F859D55-780B-4C42-8BB8-B4136492067F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9318, at 5:54 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macie=
ira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><span style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: non=
e; display: inline !important;" class=3D"">QResource also supports reading =
a resource directory directly from a file,<span class=3D"Apple-converted-sp=
ace">&nbsp;</span></span><br style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px; float: none; display: inline !important;" class=3D"">instead of som=
ething registered inside the binary image (see<span class=3D"Apple-converte=
d-space">&nbsp;</span></span><br style=3D"font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant: normal; font-weight: normal; lett=
er-spacing: normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; float: none; display: inline !important;" class=3D"">QResource=
::registerResource).</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px;=
 font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !i=
mportant;" class=3D"">But David's description is more similar to QFileSelec=
tor.</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
 -webkit-text-stroke-width: 0px;" class=3D""></div></blockquote></div><br c=
lass=3D""><div class=3D"">My suggestion is to allow the implementation to d=
ecide to store a resource inside the binary or outside. The existence of si=
milar (albeit manually-controlled) functionality in Qt is evidence that it=
=E2=80=99s useful to refer to a resource without reference to its storage m=
edium.</div><div class=3D""><br class=3D""></div><div class=3D"">All this i=
nsistence on metaprogramming is bizarre. Many GUI apps pre-scale image reso=
urces for different resolutions. As mentioned, some like to validate OpenGL=
 shaders. Is it somehow better to put Herculean effort into achieving these=
 tasks with C++ metaprogramming, instead of using ordinary tools with ordin=
ary toolchains that exist today?</div><div class=3D""><br class=3D""></div>=
<div class=3D"">The goal is to allow portable libraries to include resource=
 data. Portable specification of resource processing is not a part of this.=
 Images will be scaled differently for different platforms=E2=80=99 various=
 screen resolutions. Shaders will be validated against various platform-spe=
cific extensions and bugs, if at all. A portable library should be able to =
include raw resource files, and simple named references to them. (There are=
 semi-portable naming conventions, like <font face=3D"Courier" class=3D"">@=
4x.png</font> for a high-resolution image. Libraries can use such resource =
mappings at their own peril, it=E2=80=99s not really the concern of the C++=
 standard.)</div><div class=3D""><br class=3D""></div><div class=3D"">This =
thread is way off track. It=E2=80=99s a red flag to even be thinking about =
the notions of text encoding and string termination. Just don=E2=80=99t.</d=
iv></body></html>

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

--Apple-Mail=_9F859D55-780B-4C42-8BB8-B4136492067F--

.

--Apple-Mail=_D53C457F-6CF5-44F4-852F-6DA193E0B3AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9321, at 11:50 AM, David Krauss <potswa@gmail.co=
m> wrote:
>=20
> Is it somehow better to put Herculean effort into achieving these tasks w=
ith C++ metaprogramming, instead of using ordinary tools with ordinary tool=
chains that exist today?

Sorry, I meant Sisyphean.

--=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/.

--Apple-Mail=_D53C457F-6CF5-44F4-852F-6DA193E0B3AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9321, at 11:50 AM, David Krauss &lt;<a href=3D"mailto:potswa@gmail.c=
om" class=3D"">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inte=
rchange-newline"><div class=3D""><span style=3D"font-family: Helvetica; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: normal; orphans: auto; text-align: s=
tart; text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; displ=
ay: inline !important;" class=3D"">Is it somehow better to put Herculean ef=
fort into achieving these tasks with C++ metaprogramming, instead of using =
ordinary tools with ordinary toolchains that exist today?</span></div></blo=
ckquote></div><br class=3D""><div class=3D"">Sorry, I meant Sisyphean.</div=
></body></html>

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

--Apple-Mail=_D53C457F-6CF5-44F4-852F-6DA193E0B3AD--

.

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

David, you're so not understanding the point. It's not about resources.
It's about including a blob in a binary with an identifier to refer to it
as a raw sequence of bytes.

On Fri, Feb 20, 2015 at 10:56 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2015=E2=80=9302=E2=80=9321, at 11:50 AM, David Krauss <potswa@gmail.co=
m> wrote:
>
> Is it somehow better to put Herculean effort into achieving these tasks
> with C++ metaprogramming, instead of using ordinary tools with ordinary
> toolchains that exist today?
>
>
> Sorry, I meant Sisyphean.
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">David, you&#39;re so not understanding the point. It&#39;s=
 not about resources. It&#39;s about including a blob in a binary with an i=
dentifier to refer to it as a raw sequence of bytes.<br></div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Feb 20, 2015 at 10:56 =
PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" =
target=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div style=3D"word-wrap:break-word"><span class=3D""><br><d=
iv><blockquote type=3D"cite"><div>On 2015=E2=80=9302=E2=80=9321, at 11:50 A=
M, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">p=
otswa@gmail.com</a>&gt; wrote:</div><br><div><span style=3D"font-family:Hel=
vetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:nor=
mal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px;float:none;displ=
ay:inline!important">Is it somehow better to put Herculean effort into achi=
eving these tasks with C++ metaprogramming, instead of using ordinary tools=
 with ordinary toolchains that exist today?</span></div></blockquote></div>=
<br></span><div>Sorry, I meant Sisyphean.</div></div><div class=3D"HOEnZb">=
<div class=3D"h5">

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

--001a1134573c57f267050f92156f--

.

> On 2015=E2=80=9302=E2=80=9321, at 1:03 PM, Dale Weiler <weilercdale@gmail=
..com> wrote:
>=20
> David, you're so not understanding the point. It's not about resources. I=
t's about including a blob in a binary with an identifier to refer to it as=
 a raw sequence of bytes.

So=E2=80=A6 no graphics, or large files of any sort?

What is the motivating use case? The discussion is off track because it=E2=
=80=99s =E2=80=9Cabout=E2=80=9D a solution in search of a problem. That sol=
ution sacrifices basic usability and compatibility with existing toolchains=
, in favor of pointless metaprocessing.

Not just support for metaprocessing, but it seems you=E2=80=99re suggesting=
 that some existing external build tools, like text converters, be replicat=
ed as metaprograms.

--=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_1520_1667131932.1424504609557
Content-Type: multipart/alternative;
 boundary="----=_Part_1521_1267238715.1424504609557"

------=_Part_1521_1267238715.1424504609557
Content-Type: text/plain; charset=UTF-8

I feel like generating a string literal or sequence of tokens is too
low-level. Why not let the macro return some compiletime string from the
stdlib (we'd need such a thing first) that was initialized in an
implementation-defined way. This would allow users to do any arbitrary
processing using a constexpr function, such as appending a null terminator,
converting newlines, endian conversion, etc. We could even provide such
functions in the stdlib, thus it wouldn't need to be built into the
compiler.

--

---
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_1521_1267238715.1424504609557
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I feel like generating a string literal or sequence of tok=
ens is too low-level. Why not let the macro return some compiletime string =
from the stdlib (we'd need such a thing first) that was initialized in an i=
mplementation-defined way. This would allow users to do any arbitrary proce=
ssing using a constexpr function, such as appending a null terminator, conv=
erting newlines, endian conversion, etc. We could even provide such functio=
ns in the stdlib, thus it wouldn't need to be built into the compiler.<br><=
/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_1521_1267238715.1424504609557--
------=_Part_1520_1667131932.1424504609557--

.

--Apple-Mail=_5481C7B4-3F3F-48D1-8EEE-EB4C5829C54C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9321, at 3:43 PM, Markus Grech <markus.grech@gma=
il.com> wrote:
>=20
> I feel like generating a string literal or sequence of tokens is too low-=
level. Why not let the macro return some compiletime string from the stdlib=
 (we'd need such a thing first) that was initialized in an implementation-d=
efined way. This would allow users to do any arbitrary processing using a c=
onstexpr function, such as appending a null terminator, converting newlines=
, endian conversion, etc. We could even provide such functions in the stdli=
b, thus it wouldn't need to be built into the compiler.

Constexpr functions aren=E2=80=99t as friendly as folks here seem to assume=
.. I had the luxury of writing some constexpr table processing for a paper o=
n numerics, which didn=E2=80=99t make it to Urbana. Note:

1. You need to compute the size of the resulting array in the declaration o=
f the function that will return it. For text replacements, this can mean do=
ing everything twice.

2. All computations will be checked against all undefined behavior, so it w=
ill run slowly. There=E2=80=99s a maximum number of elementary operations a=
llowed, on the order of a million (maybe 10^5 or 10^7, I don=E2=80=99t reca=
ll), and it=E2=80=99ll take a few seconds to get there.

3. There is no heap, and even if there were (e.g., you emulate one), conste=
xpr interpretation inflates memory complexity the same as runtime.

Just because a system is Turing-complete, doesn=E2=80=99t mean it can host =
a suitable replacement for iconv or ImageMagick.

--=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/.

--Apple-Mail=_5481C7B4-3F3F-48D1-8EEE-EB4C5829C54C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9321, at 3:43 PM, Markus Grech &lt;<a href=3D"mailto:markus.grech@gm=
ail.com" class=3D"">markus.grech@gmail.com</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">I f=
eel like generating a string literal or sequence of tokens is too low-level=
.. Why not let the macro return some compiletime string from the stdlib (we'=
d need such a thing first) that was initialized in an implementation-define=
d way. This would allow users to do any arbitrary processing using a conste=
xpr function, such as appending a null terminator, converting newlines, end=
ian conversion, etc. We could even provide such functions in the stdlib, th=
us it wouldn't need to be built into the compiler.<br class=3D""></div></di=
v></blockquote><div><br class=3D""></div><div>Constexpr functions aren=E2=
=80=99t as friendly as folks here seem to assume. I had the luxury of writi=
ng some constexpr table processing for a paper on numerics, which didn=E2=
=80=99t make it to Urbana. Note:</div><div><br class=3D""></div><div>1. You=
 need to compute the size of the resulting array in the declaration of the =
function that will return it. For text replacements, this can mean doing ev=
erything twice.</div><div><br class=3D""></div><div>2. All computations wil=
l be checked against all undefined behavior, so it will run slowly. There=
=E2=80=99s a maximum number of elementary operations allowed, on the order =
of a million (maybe 10^5 or 10^7, I don=E2=80=99t recall), and it=E2=80=99l=
l take a few seconds to get there.</div><div><br class=3D""></div><div>3. T=
here is no heap, and even if there were (e.g., you emulate one), constexpr =
interpretation inflates memory complexity the same as runtime.</div><div><b=
r class=3D""></div><div>Just because a system is Turing-complete, doesn=E2=
=80=99t mean it can host a suitable replacement for <font face=3D"Courier" =
class=3D"">iconv</font> or ImageMagick.</div></div></body></html>

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

--Apple-Mail=_5481C7B4-3F3F-48D1-8EEE-EB4C5829C54C--

.

------=_Part_2383_1938319590.1424609080765
Content-Type: multipart/alternative;
 boundary="----=_Part_2384_10424140.1424609080765"

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

If we suppose what you've said is true I still think it's a better for the=
=20
program to compile slow rather than to run slow. Also this can be a user=20
choice - if he is developing a commercial program where the speed is=20
important he will try to use constexpr functions as often as possible. But=
=20
if he is a hobbyist which perhaps don't want to wait long compile-time's he=
=20
will rather choice simple functions which will be executed at run-time.

And in the case the first user will load it's resource file into the=20
program at compile-time as a built-in literal while the second one will=20
load and translate the file into char's during run-time.

=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 21 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=
=B0=D1=80=D0=B8 2015 =D0=B3., 10:26:18 UTC+2, David Krauss =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:
>
>
> On 2015=E2=80=9302=E2=80=9321, at 3:43 PM, Markus Grech <markus...@gmail.=
com <javascript:>>=20
> wrote:
>
> I feel like generating a string literal or sequence of tokens is too=20
> low-level. Why not let the macro return some compiletime string from the=
=20
> stdlib (we'd need such a thing first) that was initialized in an=20
> implementation-defined way. This would allow users to do any arbitrary=20
> processing using a constexpr function, such as appending a null terminato=
r,=20
> converting newlines, endian conversion, etc. We could even provide such=
=20
> functions in the stdlib, thus it wouldn't need to be built into the=20
> compiler.
>
>
> Constexpr functions aren=E2=80=99t as friendly as folks here seem to assu=
me. I had=20
> the luxury of writing some constexpr table processing for a paper on=20
> numerics, which didn=E2=80=99t make it to Urbana. Note:
>
> 1. You need to compute the size of the resulting array in the declaration=
=20
> of the function that will return it. For text replacements, this can mean=
=20
> doing everything twice.
>
> 2. All computations will be checked against all undefined behavior, so it=
=20
> will run slowly. There=E2=80=99s a maximum number of elementary operation=
s allowed,=20
> on the order of a million (maybe 10^5 or 10^7, I don=E2=80=99t recall), a=
nd it=E2=80=99ll=20
> take a few seconds to get there.
>
> 3. There is no heap, and even if there were (e.g., you emulate one),=20
> constexpr interpretation inflates memory complexity the same as runtime.
>
> Just because a system is Turing-complete, doesn=E2=80=99t mean it can hos=
t a=20
> suitable replacement for iconv or ImageMagick.
>

--=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_2384_10424140.1424609080765
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">If we suppose what you've said is true I still think it's =
a better for the program to compile slow rather than to run slow. Also this=
 can be a user choice - if he is developing a commercial program where the =
speed is important he will try to use constexpr functions as often as possi=
ble. But if he is a hobbyist which perhaps don't want to wait long compile-=
time's he will rather choice simple functions which will be executed at run=
-time.<div><br></div><div>And in the case the first user will load it's res=
ource file into the program at compile-time as a built-in literal while the=
 second one will load and translate the file into char's during run-time.<b=
r><br>=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 21 =D1=84=D0=B5=D0=B2=D1=80=D1=
=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 10:26:18 UTC+2, David Krauss =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv style=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>O=
n 2015=E2=80=9302=E2=80=9321, at 3:43 PM, Markus Grech &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"WjMeULnGF3kJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">markus...@gmail.com</a>&gt; wrote:</d=
iv><br><div><div dir=3D"ltr">I feel like generating a string literal or seq=
uence of tokens is too low-level. Why not let the macro return some compile=
time string from the stdlib (we'd need such a thing first) that was initial=
ized in an implementation-defined way. This would allow users to do any arb=
itrary processing using a constexpr function, such as appending a null term=
inator, converting newlines, endian conversion, etc. We could even provide =
such functions in the stdlib, thus it wouldn't need to be built into the co=
mpiler.<br></div></div></blockquote><div><br></div><div>Constexpr functions=
 aren=E2=80=99t as friendly as folks here seem to assume. I had the luxury =
of writing some constexpr table processing for a paper on numerics, which d=
idn=E2=80=99t make it to Urbana. Note:</div><div><br></div><div>1. You need=
 to compute the size of the resulting array in the declaration of the funct=
ion that will return it. For text replacements, this can mean doing everyth=
ing twice.</div><div><br></div><div>2. All computations will be checked aga=
inst all undefined behavior, so it will run slowly. There=E2=80=99s a maxim=
um number of elementary operations allowed, on the order of a million (mayb=
e 10^5 or 10^7, I don=E2=80=99t recall), and it=E2=80=99ll take a few secon=
ds to get there.</div><div><br></div><div>3. There is no heap, and even if =
there were (e.g., you emulate one), constexpr interpretation inflates memor=
y complexity the same as runtime.</div><div><br></div><div>Just because a s=
ystem is Turing-complete, doesn=E2=80=99t mean it can host a suitable repla=
cement for <font face=3D"Courier">iconv</font> or ImageMagick.</div></div><=
/div></blockquote></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_2384_10424140.1424609080765--
------=_Part_2383_1938319590.1424609080765--

.

------=_Part_56_843755714.1424616650352
Content-Type: multipart/alternative;
 boundary="----=_Part_57_1167764057.1424616650352"

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



On Sunday, February 22, 2015 at 7:44:40 AM UTC-5, Alexander Nikolov wrote:
>
> If we suppose what you've said is true I still think it's a better for th=
e=20
> program to compile slow rather than to run slow. Also this can be a user=
=20
> choice - if he is developing a commercial program where the speed is=20
> important he will try to use constexpr functions as often as possible. Bu=
t=20
> if he is a hobbyist which perhaps don't want to wait long compile-time's =
he=20
> will rather choice simple functions which will be executed at run-time.
>
> And in the case the first user will load it's resource file into the=20
> program at compile-time as a built-in literal while the second one will=
=20
> load and translate the file into char's during run-time.
>
> =D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 21 =D1=84=D0=B5=D0=B2=D1=80=D1=83=
=D0=B0=D1=80=D0=B8 2015 =D0=B3., 10:26:18 UTC+2, David Krauss =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>>
>>
>> On 2015=E2=80=9302=E2=80=9321, at 3:43 PM, Markus Grech <markus...@gmail=
..com> wrote:
>>
>> I feel like generating a string literal or sequence of tokens is too=20
>> low-level. Why not let the macro return some compiletime string from the=
=20
>> stdlib (we'd need such a thing first) that was initialized in an=20
>> implementation-defined way. This would allow users to do any arbitrary=
=20
>> processing using a constexpr function, such as appending a null terminat=
or,=20
>> converting newlines, endian conversion, etc. We could even provide such=
=20
>> functions in the stdlib, thus it wouldn't need to be built into the=20
>> compiler.
>>
>>
>> Constexpr functions aren=E2=80=99t as friendly as folks here seem to ass=
ume. I=20
>> had the luxury of writing some constexpr table processing for a paper on=
=20
>> numerics, which didn=E2=80=99t make it to Urbana. Note:
>>
>> 1. You need to compute the size of the resulting array in the declaratio=
n=20
>> of the function that will return it. For text replacements, this can mea=
n=20
>> doing everything twice.
>>
>> 2. All computations will be checked against all undefined behavior, so i=
t=20
>> will run slowly. There=E2=80=99s a maximum number of elementary operatio=
ns allowed,=20
>> on the order of a million (maybe 10^5 or 10^7, I don=E2=80=99t recall), =
and it=E2=80=99ll=20
>> take a few seconds to get there.
>>
>> 3. There is no heap, and even if there were (e.g., you emulate one),=20
>> constexpr interpretation inflates memory complexity the same as runtime.
>>
>> Just because a system is Turing-complete, doesn=E2=80=99t mean it can ho=
st a=20
>> suitable replacement for iconv or ImageMagick.
>>
>
I wouldn't recommend using meta-programming to convert image formats or do=
=20
any kind of complex processing like that. Not only would it be slow for all=
=20
of the reasons you mentioned but also very painful to write and maintain.=
=20
What it could be useful for is for simple on-disk to native transformations=
=20
like converting newlines, adding/removing null terminaton, endian=20
conversion, unpacking a packed struct into a native struct..

Anyway the idea of compile time pre-processing of the data is extra. All of=
=20
it can be done in the library and would not need to be part of any initial=
=20
proposal.=20

--=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_57_1167764057.1424616650352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, February 22, 2015 at 7:44:40 AM UTC-5, =
Alexander Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">If we suppose what you've said is true I still think it's a bett=
er for the program to compile slow rather than to run slow. Also this can b=
e a user choice - if he is developing a commercial program where the speed =
is important he will try to use constexpr functions as often as possible. B=
ut if he is a hobbyist which perhaps don't want to wait long compile-time's=
 he will rather choice simple functions which will be executed at run-time.=
<div><br></div><div>And in the case the first user will load it's resource =
file into the program at compile-time as a built-in literal while the secon=
d one will load and translate the file into char's during run-time.<br><br>=
=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 21 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=
=B0=D1=80=D0=B8 2015 =D0=B3., 10:26:18 UTC+2, David Krauss =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D=
"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=
=80=9302=E2=80=9321, at 3:43 PM, Markus Grech &lt;<a rel=3D"nofollow">marku=
s...@gmail.com</a>&gt; wrote:</div><br><div><div dir=3D"ltr">I feel like ge=
nerating a string literal or sequence of tokens is too low-level. Why not l=
et the macro return some compiletime string from the stdlib (we'd need such=
 a thing first) that was initialized in an implementation-defined way. This=
 would allow users to do any arbitrary processing using a constexpr functio=
n, such as appending a null terminator, converting newlines, endian convers=
ion, etc. We could even provide such functions in the stdlib, thus it would=
n't need to be built into the compiler.<br></div></div></blockquote><div><b=
r></div><div>Constexpr functions aren=E2=80=99t as friendly as folks here s=
eem to assume. I had the luxury of writing some constexpr table processing =
for a paper on numerics, which didn=E2=80=99t make it to Urbana. Note:</div=
><div><br></div><div>1. You need to compute the size of the resulting array=
 in the declaration of the function that will return it. For text replaceme=
nts, this can mean doing everything twice.</div><div><br></div><div>2. All =
computations will be checked against all undefined behavior, so it will run=
 slowly. There=E2=80=99s a maximum number of elementary operations allowed,=
 on the order of a million (maybe 10^5 or 10^7, I don=E2=80=99t recall), an=
d it=E2=80=99ll take a few seconds to get there.</div><div><br></div><div>3=
.. There is no heap, and even if there were (e.g., you emulate one), constex=
pr interpretation inflates memory complexity the same as runtime.</div><div=
><br></div><div>Just because a system is Turing-complete, doesn=E2=80=99t m=
ean it can host a suitable replacement for <font face=3D"Courier">iconv</fo=
nt> or ImageMagick.</div></div></div></blockquote></div></div></blockquote>=
<div><br></div><div>I wouldn't recommend using meta-programming to convert =
image formats or do any kind of complex processing like that. Not only woul=
d it be slow for all of the reasons you mentioned but also very painful to =
write and maintain. What it could be useful for is for simple on-disk to na=
tive transformations like converting newlines, adding/removing null termina=
ton, endian conversion, unpacking a packed struct into a native struct..</d=
iv><div><br></div><div>Anyway the idea of compile time pre-processing of th=
e data is extra. All of it can be done in the library and would not need to=
 be part of any initial proposal.&nbsp;</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_57_1167764057.1424616650352--
------=_Part_56_843755714.1424616650352--

.

On Sunday 22 February 2015 04:44:40 Alexander Nikolov wrote:
> If we suppose what you've said is true I still think it's a better for the
> program to compile slow rather than to run slow. Also this can be a user
> choice - if he is developing a commercial program where the speed is
> important he will try to use constexpr functions as often as possible. But
> if he is a hobbyist which perhaps don't want to wait long compile-time's he
> will rather choice simple functions which will be executed at run-time.

Just to be clear:. constexpr functions are fast if they get executed at
compile-time, but if you make a mistake and they get run at runtime instead,
they are slower than the runtime-only equivalent.

--
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 2015-02-21 00:03, Dale Weiler wrote:
> David, you're so not understanding the point. It's not about resources.
> It's about including a blob in a binary with an identifier to refer to it
> as a raw sequence of bytes.

Actually I think he's spot on.

David's point (which I've also repeated several times) is in fact
specifically to *focus* on "including a blob in a binary with an
identifier to refer to it as a raw sequence of bytes", rather than
getting distracted with all sorts of bells and whistles related to
content validation, transformation, magical loading of different blobs
based on run-time state, etc.

(Note: as far as I'm concerned, a blob of data that is not code *is* a
"resource" :-).)

--
Matthew

--

---
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_540_2045411855.1424719278999
Content-Type: multipart/alternative;
 boundary="----=_Part_541_318825809.1424719279000"

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

Never knew that. Is it a rule and where is exactly in the standard is=20
defined?

As far as I've looked it into 'n4296' - the paper never mentioned anything=
=20
about 'constexpr function' execution speed. Or is it such thing even=20
defined in it - 'execution speed'?

Perhaps the closest thing I could find is the way they are called, which is=
=20
the same way as other 'normal' (non-constexpr) functions, and so the time=
=20
in which is done should be the same too:

=C2=A7 7.1.5.7:

>  A call to a constexpr function produces the same result as a call to an=
=20
> equivalent non-constexpr function in all respects except that a call to a=
=20
> constexpr function can appear in a constant expression.=20


=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 22 =D1=84=D0=B5=D0=B2=D1=80=D1=83=D0=
=B0=D1=80=D0=B8 2015 =D0=B3., 20:08:29 UTC+2, Thiago Macieira =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
>
> On Sunday 22 February 2015 04:44:40 Alexander Nikolov wrote:=20
> > If we suppose what you've said is true I still think it's a better for=
=20
> the=20
> > program to compile slow rather than to run slow. Also this can be a use=
r=20
> > choice - if he is developing a commercial program where the speed is=20
> > important he will try to use constexpr functions as often as possible.=
=20
> But=20
> > if he is a hobbyist which perhaps don't want to wait long compile-time'=
s=20
> he=20
> > will rather choice simple functions which will be executed at run-time.=
=20
>
> Just to be clear:. constexpr functions are fast if they get executed at=
=20
> compile-time, but if you make a mistake and they get run at runtime=20
> instead,=20
> they are slower than the runtime-only equivalent.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

--=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_541_318825809.1424719279000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Never knew that. Is it a rule and where is exactly in the =
standard is defined?<div><br></div><div>As far as I've looked it into 'n429=
6' - the paper never mentioned anything about 'constexpr function' executio=
n speed. Or is it such thing even defined in it - 'execution speed'?</div><=
div><br></div><div>Perhaps the closest thing I could find is the way they a=
re called, which is the same way as other 'normal' (non-constexpr) function=
s, and so the time in which is done should be the same too:</div><div><br><=
/div><div>=C2=A7 7.1.5.7:<br></div><div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-colo=
r: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">&nbsp;=
A call to a constexpr function produces the same result as a call to an equ=
ivalent non-constexpr function in all respects except that a call to a cons=
texpr function can appear in a constant expression.&nbsp;</blockquote><div>=
<br></div><div>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 22 =D1=84=D0=B5=D0=B2=
=D1=80=D1=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 20:08:29 UTC+2, Thiago Macieir=
a =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">On Sunday 22 February 2015 04:44:40 Alexander Nikolov wrote:
<br>&gt; If we suppose what you've said is true I still think it's a better=
 for the=20
<br>&gt; program to compile slow rather than to run slow. Also this can be =
a user=20
<br>&gt; choice - if he is developing a commercial program where the speed =
is=20
<br>&gt; important he will try to use constexpr functions as often as possi=
ble. But=20
<br>&gt; if he is a hobbyist which perhaps don't want to wait long compile-=
time's he=20
<br>&gt; will rather choice simple functions which will be executed at run-=
time.
<br>
<br>Just to be clear:. constexpr functions are fast if they get executed at=
=20
<br>compile-time, but if you make a mistake and they get run at runtime ins=
tead,=20
<br>they are slower than the runtime-only equivalent.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></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 />

------=_Part_541_318825809.1424719279000--
------=_Part_540_2045411855.1424719278999--

.

On Monday 23 February 2015 11:21:18 Alexander Nikolov wrote:
> Never knew that. Is it a rule and where is exactly in the standard is
> defined?

It's not a rule, it's a consequence of the restrictions on what you can do on
constexpr functions.

--
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_1873_1142687793.1425140763023
Content-Type: multipart/alternative;
 boundary="----=_Part_1874_1781157729.1425140763024"

------=_Part_1874_1781157729.1425140763024
Content-Type: text/plain; charset=UTF-8

On Sunday, February 15, 2015 at 7:38:53 PM UTC+1, tdh...@gmail.com wrote:
>
> Hi,
>
> Apologies if this has been discussed before. This is something I've wanted
> in C++ for ages and it seems trivial, so here goes my (first ever) informal
> proposal. Let me know what you think!
>

I've though of something like this before, see
https://groups.google.com/a/isocpp.org/forum/?hl=en&fromgroups#!searchin/std-proposals/olaf$20spek$20include/std-proposals/WciaY0IJ4ak/CASRo59bXVIJ


--

---
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_1874_1781157729.1425140763024
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, February 15, 2015 at 7:38:53 PM UTC+1, tdh...@g=
mail.com 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=
">Hi,<div><br></div><div>Apologies if this has been discussed before. This =
is something I've wanted in C++ for ages and it seems trivial, so here goes=
 my (first ever) informal proposal. Let me know what you think!</div></div>=
</blockquote><div><br></div><div>I've though of something like this before,=
 see</div><div>https://groups.google.com/a/isocpp.org/forum/?hl=3Den&amp;fr=
omgroups#!searchin/std-proposals/olaf$20spek$20include/std-proposals/WciaY0=
IJ4ak/CASRo59bXVIJ&nbsp;</div><div><br></div><div><br></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_1874_1781157729.1425140763024--
------=_Part_1873_1142687793.1425140763023--

.