------=_Part_535_985363023.1545490908769
Content-Type: multipart/alternative;
 boundary="----=_Part_536_776797495.1545490908769"

------=_Part_536_776797495.1545490908769
Content-Type: text/plain; charset="UTF-8"

Hi!

I worked with OpenGL and OpenCL in the last years and I oftenly found
myself needing a function to read a text file into a std::string variable
(i.e. to read a shader or kernel program source file and pass it to
OpenCL/OpenGL). While there are some good solutions on stackoverflow
<https://stackoverflow.com/a/2602060> I wonder why there is no such
facility in the standard library or at least in the Boost libraries.

In Java one could use something like:
new String(Files.readAllBytes(Paths.get(path)), encoding);

In C# there is:
string File.ReadAllText(string path, Encoding encoding);

Furthermore, a binary equivalent would also be useful, e.g. to read a file
to a std::vector<std::byte>.

Does anybody know, why such a facility has not made it into the standard
yet?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/101123f3-31a9-49cf-b736-90dc00121b02%40isocpp.org.

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

<div dir=3D"ltr">Hi!<br><br>I worked with OpenGL and OpenCL in the last yea=
rs and I oftenly found myself needing a function to read a text file into a=
 std::string variable (i.e. to read a shader or kernel program source file =
and pass it to OpenCL/OpenGL). While there are some good solutions on <a hr=
ef=3D"https://stackoverflow.com/a/2602060">stackoverflow</a>=C2=A0I wonder =
why there is no such facility in the standard library or at least in the Bo=
ost libraries.<div><br></div><div>In Java one could use something like:</di=
v><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; overflow-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: rgb(34, 34, 34); font-family: Arial, =
Helvetica, sans-serif; background-color: rgb(255, 255, 255);"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">new</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">String</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Files</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">readAllBytes</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Pat=
hs</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">get</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">path</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)),</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> encoding</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">);</span></span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>In C# there is=
:</div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; overflow-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"font-family: Arial, Helvetica, sans-ser=
if; background-color: rgb(255, 255, 255);"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">File</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">.</span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
ReadAllText</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> path</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">Encoding</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> encoding</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">);</span></span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Furth=
ermore, a binary equivalent would also be useful, e.g. to read a file to a =
std::vector&lt;std::byte&gt;.</div><div><br></div><div>Does anybody know, w=
hy such a facility has not made it into the standard yet?</div></div>

<p></p>

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

------=_Part_536_776797495.1545490908769--

------=_Part_535_985363023.1545490908769--

.

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

The reasons something isn't in C++ is because either (a) noone has formally
proposed it; (b) the proposal was rejected; or (c) the proposal is still
being refined.

I think in this case it's (a).

I think a pair of conveniance functions that "load entire file into a
string" and a companion "create/overwrite entire file from a string" sound
reasonable, I've observed such functions in numerous third party base
libraries.

I encourage you to proceed with a formal proposal.  See
https://isocpp.org/std/submit-a-proposal.  Feel free to send a draft to
this list for review.


On Sun, Dec 23, 2018 at 1:01 AM Bernhard Manfred Gruber <
bernhardmgruber@gmail.com> wrote:

> Hi!
>
> I worked with OpenGL and OpenCL in the last years and I oftenly found
> myself needing a function to read a text file into a std::string variable
> (i.e. to read a shader or kernel program source file and pass it to
> OpenCL/OpenGL). While there are some good solutions on stackoverflow
> <https://stackoverflow.com/a/2602060> I wonder why there is no such
> facility in the standard library or at least in the Boost libraries.
>
> In Java one could use something like:
> new String(Files.readAllBytes(Paths.get(path)), encoding);
>
> In C# there is:
> string File.ReadAllText(string path, Encoding encoding);
>
> Furthermore, a binary equivalent would also be useful, e.g. to read a file
> to a std::vector<std::byte>.
>
> Does anybody know, why such a facility has not made it into the standard
> yet?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/101123f3-31a9-49cf-b736-90dc00121b02%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/101123f3-31a9-49cf-b736-90dc00121b02%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKUb%3DhV%3DXy1BM0GrwPycY6GUyNmCNSBKJCE1vFyVGR9ew%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"ltr">The reasons something isn&#39;t in C++ is=
 because either (a) noone has formally proposed it; (b) the proposal was re=
jected; or (c) the proposal is still being refined.<div><br></div><div>I th=
ink in this case it&#39;s (a).</div><div><br></div><div>I think a pair of c=
onveniance functions that &quot;load entire file into a string&quot; and a =
companion &quot;create/overwrite entire file from a string&quot; sound reas=
onable, I&#39;ve observed such functions in numerous third party base libra=
ries.</div><div><br></div><div>I encourage you to proceed with a formal pro=
posal.=C2=A0 See <a href=3D"https://isocpp.org/std/submit-a-proposal">https=
://isocpp.org/std/submit-a-proposal</a>.=C2=A0=C2=A0Feel free to send a dra=
ft to this list for review.</div><div><br></div><div></div></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Dec 23, 2018 at 1:01 AM=
 Bernhard Manfred Gruber &lt;<a href=3D"mailto:bernhardmgruber@gmail.com">b=
ernhardmgruber@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr">Hi!<br><br>I worked with OpenGL an=
d OpenCL in the last years and I oftenly found myself needing a function to=
 read a text file into a std::string variable (i.e. to read a shader or ker=
nel program source file and pass it to OpenCL/OpenGL). While there are some=
 good solutions on <a href=3D"https://stackoverflow.com/a/2602060" target=
=3D"_blank">stackoverflow</a>=C2=A0I wonder why there is no such facility i=
n the standard library or at least in the Boost libraries.<div><br></div><d=
iv>In Java one could use something like:</div><div><div class=3D"gmail-m_52=
53261487476615309prettyprint" style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px"><code clas=
s=3D"gmail-m_5253261487476615309prettyprint"><div class=3D"gmail-m_52532614=
87476615309subprettyprint"><span style=3D"color:rgb(34,34,34);font-family:A=
rial,Helvetica,sans-serif;background-color:rgb(255,255,255)"><span style=3D=
"color:rgb(0,0,136)" class=3D"gmail-m_5253261487476615309styled-by-prettify=
">new</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_5253261487476=
615309styled-by-prettify"> </span><span style=3D"color:rgb(102,0,102)" clas=
s=3D"gmail-m_5253261487476615309styled-by-prettify">String</span><span styl=
e=3D"color:rgb(102,102,0)" class=3D"gmail-m_5253261487476615309styled-by-pr=
ettify">(</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_52532=
61487476615309styled-by-prettify">Files</span><span style=3D"color:rgb(102,=
102,0)" class=3D"gmail-m_5253261487476615309styled-by-prettify">.</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_5253261487476615309styled-by=
-prettify">readAllBytes</span><span style=3D"color:rgb(102,102,0)" class=3D=
"gmail-m_5253261487476615309styled-by-prettify">(</span><span style=3D"colo=
r:rgb(102,0,102)" class=3D"gmail-m_5253261487476615309styled-by-prettify">P=
aths</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_5253261487=
476615309styled-by-prettify">.</span><span style=3D"color:rgb(0,0,136)" cla=
ss=3D"gmail-m_5253261487476615309styled-by-prettify">get</span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_5253261487476615309styled-by-pre=
ttify">(</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_5253261487=
476615309styled-by-prettify">path</span><span style=3D"color:rgb(102,102,0)=
" class=3D"gmail-m_5253261487476615309styled-by-prettify">)),</span><span s=
tyle=3D"color:rgb(0,0,0)" class=3D"gmail-m_5253261487476615309styled-by-pre=
ttify"> encoding</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_5253261487476615309styled-by-prettify">);</span></span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_5253261487476615309styled-by-prettify"><br>=
</span></div></code></div><br>In C# there is:</div><div><div class=3D"gmail=
-m_5253261487476615309prettyprint" style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code=
 class=3D"gmail-m_5253261487476615309prettyprint"><div class=3D"gmail-m_525=
3261487476615309subprettyprint"><span style=3D"font-family:Arial,Helvetica,=
sans-serif;background-color:rgb(255,255,255)"><span style=3D"color:rgb(0,0,=
136)" class=3D"gmail-m_5253261487476615309styled-by-prettify">string</span>=
<span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_5253261487476615309styled=
-by-prettify"> </span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m=
_5253261487476615309styled-by-prettify">File</span><span style=3D"color:rgb=
(102,102,0)" class=3D"gmail-m_5253261487476615309styled-by-prettify">.</spa=
n><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_5253261487476615309=
styled-by-prettify">ReadAllText</span><span style=3D"color:rgb(102,102,0)" =
class=3D"gmail-m_5253261487476615309styled-by-prettify">(</span><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_5253261487476615309styled-by-prett=
ify">string</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_5253261=
487476615309styled-by-prettify"> path</span><span style=3D"color:rgb(102,10=
2,0)" class=3D"gmail-m_5253261487476615309styled-by-prettify">,</span><span=
 style=3D"color:rgb(0,0,0)" class=3D"gmail-m_5253261487476615309styled-by-p=
rettify"> </span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_5253=
261487476615309styled-by-prettify">Encoding</span><span style=3D"color:rgb(=
0,0,0)" class=3D"gmail-m_5253261487476615309styled-by-prettify"> encoding</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_5253261487476615=
309styled-by-prettify">);</span></span><span style=3D"color:rgb(0,0,0)" cla=
ss=3D"gmail-m_5253261487476615309styled-by-prettify"><br></span></div></cod=
e></div><br>Furthermore, a binary equivalent would also be useful, e.g. to =
read a file to a std::vector&lt;std::byte&gt;.</div><div><br></div><div>Doe=
s anybody know, why such a facility has not made it into the standard yet?<=
/div></div>

<p></p>

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

<p></p>

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

--00000000000037fd57057d9dddf2--

.

--0000000000002292f3057d9eae4b
Content-Type: text/plain; charset="UTF-8"

Of course "load file into string" isn't really what you want here. All you
need to do is "map file into memory". The file just happens to have text in
it.

Native memory mapping is trivial with mmap on unix-like systems. (I use a
simple wrapper around mmap and fopen). A slighly more abstract and
cross-platform interface is available in the boost interprocess library.

On Sat, 22 Dec 2018 at 15:17, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> The reasons something isn't in C++ is because either (a) noone has
> formally proposed it; (b) the proposal was rejected; or (c) the proposal is
> still being refined.
>
> I think in this case it's (a).
>
> I think a pair of conveniance functions that "load entire file into a
> string" and a companion "create/overwrite entire file from a string" sound
> reasonable, I've observed such functions in numerous third party base
> libraries.
>
> I encourage you to proceed with a formal proposal.  See
> https://isocpp.org/std/submit-a-proposal.  Feel free to send a draft to
> this list for review.
>
>
> On Sun, Dec 23, 2018 at 1:01 AM Bernhard Manfred Gruber <
> bernhardmgruber@gmail.com> wrote:
>
>> Hi!
>>
>> I worked with OpenGL and OpenCL in the last years and I oftenly found
>> myself needing a function to read a text file into a std::string variable
>> (i.e. to read a shader or kernel program source file and pass it to
>> OpenCL/OpenGL). While there are some good solutions on stackoverflow
>> <https://stackoverflow.com/a/2602060> I wonder why there is no such
>> facility in the standard library or at least in the Boost libraries.
>>
>> In Java one could use something like:
>> new String(Files.readAllBytes(Paths.get(path)), encoding);
>>
>> In C# there is:
>> string File.ReadAllText(string path, Encoding encoding);
>>
>> Furthermore, a binary equivalent would also be useful, e.g. to read a
>> file to a std::vector<std::byte>.
>>
>> Does anybody know, why such a facility has not made it into the standard
>> yet?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/101123f3-31a9-49cf-b736-90dc00121b02%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/101123f3-31a9-49cf-b736-90dc00121b02%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKUb%3DhV%3DXy1BM0GrwPycY6GUyNmCNSBKJCE1vFyVGR9ew%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKUb%3DhV%3DXy1BM0GrwPycY6GUyNmCNSBKJCE1vFyVGR9ew%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


--
Richard Hodges
hodges.r@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212 (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ5u1akdKHvkk%3D7HoS5iWwK%2BHEnFQT8sBP76B1VWoKh0w%40mail.gmail.com.

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

<div dir=3D"ltr">Of course &quot;load file into string&quot; isn&#39;t real=
ly what you want here. All you need to do is &quot;map file into memory&quo=
t;. The file just happens to have text in it.<div><br></div><div>Native mem=
ory mapping is trivial with mmap on unix-like systems. (I use a simple wrap=
per around mmap and fopen). A slighly more abstract and cross-platform inte=
rface is available in the boost interprocess library.</div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr">On Sat, 22 Dec 2018 at 15:17, Andrew =
Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div dir=3D"ltr">The reasons something isn&#39;t in C++=
 is because either (a) noone has formally proposed it; (b) the proposal was=
 rejected; or (c) the proposal is still being refined.<div><br></div><div>I=
 think in this case it&#39;s (a).</div><div><br></div><div>I think a pair o=
f conveniance functions that &quot;load entire file into a string&quot; and=
 a companion &quot;create/overwrite entire file from a string&quot; sound r=
easonable, I&#39;ve observed such functions in numerous third party base li=
braries.</div><div><br></div><div>I encourage you to proceed with a formal =
proposal.=C2=A0 See <a href=3D"https://isocpp.org/std/submit-a-proposal" ta=
rget=3D"_blank">https://isocpp.org/std/submit-a-proposal</a>.=C2=A0=C2=A0Fe=
el free to send a draft to this list for review.</div><div><br></div><div><=
/div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, De=
c 23, 2018 at 1:01 AM Bernhard Manfred Gruber &lt;<a href=3D"mailto:bernhar=
dmgruber@gmail.com" target=3D"_blank">bernhardmgruber@gmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">Hi!<br><br>I worked with OpenGL and OpenCL in the last years and I oft=
enly found myself needing a function to read a text file into a std::string=
 variable (i.e. to read a shader or kernel program source file and pass it =
to OpenCL/OpenGL). While there are some good solutions on <a href=3D"https:=
//stackoverflow.com/a/2602060" target=3D"_blank">stackoverflow</a>=C2=A0I w=
onder why there is no such facility in the standard library or at least in =
the Boost libraries.<div><br></div><div>In Java one could use something lik=
e:</div><div><div class=3D"gmail-m_7792279662371922292gmail-m_5253261487476=
615309prettyprint" style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px"><code class=3D"gmail-=
m_7792279662371922292gmail-m_5253261487476615309prettyprint"><div class=3D"=
gmail-m_7792279662371922292gmail-m_5253261487476615309subprettyprint"><span=
 style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;backgr=
ound-color:rgb(255,255,255)"><span style=3D"color:rgb(0,0,136)" class=3D"gm=
ail-m_7792279662371922292gmail-m_5253261487476615309styled-by-prettify">new=
</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_779227966237192229=
2gmail-m_5253261487476615309styled-by-prettify"> </span><span style=3D"colo=
r:rgb(102,0,102)" class=3D"gmail-m_7792279662371922292gmail-m_5253261487476=
615309styled-by-prettify">String</span><span style=3D"color:rgb(102,102,0)"=
 class=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309styled-by-p=
rettify">(</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_7792=
279662371922292gmail-m_5253261487476615309styled-by-prettify">Files</span><=
span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_7792279662371922292gma=
il-m_5253261487476615309styled-by-prettify">.</span><span style=3D"color:rg=
b(0,0,0)" class=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309st=
yled-by-prettify">readAllBytes</span><span style=3D"color:rgb(102,102,0)" c=
lass=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309styled-by-pre=
ttify">(</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_779227=
9662371922292gmail-m_5253261487476615309styled-by-prettify">Paths</span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"gmail-m_7792279662371922292gmail=
-m_5253261487476615309styled-by-prettify">.</span><span style=3D"color:rgb(=
0,0,136)" class=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309st=
yled-by-prettify">get</span><span style=3D"color:rgb(102,102,0)" class=3D"g=
mail-m_7792279662371922292gmail-m_5253261487476615309styled-by-prettify">(<=
/span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_7792279662371922292=
gmail-m_5253261487476615309styled-by-prettify">path</span><span style=3D"co=
lor:rgb(102,102,0)" class=3D"gmail-m_7792279662371922292gmail-m_52532614874=
76615309styled-by-prettify">)),</span><span style=3D"color:rgb(0,0,0)" clas=
s=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309styled-by-pretti=
fy"> encoding</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_7=
792279662371922292gmail-m_5253261487476615309styled-by-prettify">);</span><=
/span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_7792279662371922292=
gmail-m_5253261487476615309styled-by-prettify"><br></span></div></code></di=
v><br>In C# there is:</div><div><div class=3D"gmail-m_7792279662371922292gm=
ail-m_5253261487476615309prettyprint" style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><c=
ode class=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309prettypr=
int"><div class=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309su=
bprettyprint"><span style=3D"font-family:Arial,Helvetica,sans-serif;backgro=
und-color:rgb(255,255,255)"><span style=3D"color:rgb(0,0,136)" class=3D"gma=
il-m_7792279662371922292gmail-m_5253261487476615309styled-by-prettify">stri=
ng</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_7792279662371922=
292gmail-m_5253261487476615309styled-by-prettify"> </span><span style=3D"co=
lor:rgb(102,0,102)" class=3D"gmail-m_7792279662371922292gmail-m_52532614874=
76615309styled-by-prettify">File</span><span style=3D"color:rgb(102,102,0)"=
 class=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309styled-by-p=
rettify">.</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_7792=
279662371922292gmail-m_5253261487476615309styled-by-prettify">ReadAllText</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_7792279662371922=
292gmail-m_5253261487476615309styled-by-prettify">(</span><span style=3D"co=
lor:rgb(0,0,136)" class=3D"gmail-m_7792279662371922292gmail-m_5253261487476=
615309styled-by-prettify">string</span><span style=3D"color:rgb(0,0,0)" cla=
ss=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309styled-by-prett=
ify"> path</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_7792=
279662371922292gmail-m_5253261487476615309styled-by-prettify">,</span><span=
 style=3D"color:rgb(0,0,0)" class=3D"gmail-m_7792279662371922292gmail-m_525=
3261487476615309styled-by-prettify"> </span><span style=3D"color:rgb(102,0,=
102)" class=3D"gmail-m_7792279662371922292gmail-m_5253261487476615309styled=
-by-prettify">Encoding</span><span style=3D"color:rgb(0,0,0)" class=3D"gmai=
l-m_7792279662371922292gmail-m_5253261487476615309styled-by-prettify"> enco=
ding</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_7792279662=
371922292gmail-m_5253261487476615309styled-by-prettify">);</span></span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_7792279662371922292gmail-m_5=
253261487476615309styled-by-prettify"><br></span></div></code></div><br>Fur=
thermore, a binary equivalent would also be useful, e.g. to read a file to =
a std::vector&lt;std::byte&gt;.</div><div><br></div><div>Does anybody know,=
 why such a facility has not made it into the standard yet?</div></div>

<p></p>

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

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKUb%3DhV%3DXy1BM0GrwPycY6GUy=
NmCNSBKJCE1vFyVGR9ew%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAB%2B4KHKUb%3DhV%3DXy1BM0GrwPycY6GUyNmCNSBKJCE1vFyVGR9ew%40mail=
..gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr">Richard Hodges<div><a href=3D"m=
ailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a></div><di=
v>office: +442032898513</div><div>home: +376841522</div><div>mobile:=C2=A0+=
376380212 (this will be *expensive* outside Andorra!)</div><div>skype: madm=
ongo</div><div>facebook: hodges.r</div><div><br></div></div></div>

<p></p>

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

--0000000000002292f3057d9eae4b--

.

On Saturday, 22 December 2018 14:15:52 -02 Richard Hodges wrote:
> Of course "load file into string" isn't really what you want here. All you
> need to do is "map file into memory". The file just happens to have text in
> it.
>
> Native memory mapping is trivial with mmap on unix-like systems. (I use a
> simple wrapper around mmap and fopen). A slighly more abstract and
> cross-platform interface is available in the boost interprocess library.

He may actually need "read into std::string" if the sink API that he needs to
work with takes a std::string.

But it's actually far more likely that the API takes something else. In fact,
in the OP's scenario, a C API like OpenGL will not be dealing in terms of
std::string. It's trivial to create a std::string out of a std::string_view or
std::array_view or equivalent, so that should be the direction this proposal
should take. Whether the API maps or reads should also be discussed, or
whether it's allowed to heuristically choose.

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



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4713808.zOVJbe1mza%40tjmaciei-mobl1.

.

------=_Part_1106_895220184.1545542331862
Content-Type: multipart/alternative;
 boundary="----=_Part_1107_1042729583.1545542331863"

------=_Part_1107_1042729583.1545542331863
Content-Type: text/plain; charset="UTF-8"

On Saturday, December 22, 2018 at 7:21:50 PM UTC-5, Thiago Macieira wrote:
>
> On Saturday, 22 December 2018 14:15:52 -02 Richard Hodges wrote:
> > Of course "load file into string" isn't really what you want here. All
> you
> > need to do is "map file into memory". The file just happens to have text
> in
> > it.
> >
> > Native memory mapping is trivial with mmap on unix-like systems. (I use
> a
> > simple wrapper around mmap and fopen). A slighly more abstract and
> > cross-platform interface is available in the boost interprocess library.
>
> He may actually need "read into std::string" if the sink API that he needs
> to
> work with takes a std::string.
>
> But it's actually far more likely that the API takes something else. In
> fact,
> in the OP's scenario, a C API like OpenGL will not be dealing in terms of
> std::string. It's trivial to create a std::string out of a
> std::string_view or
> std::array_view or equivalent, so that should be the direction this
> proposal
> should take. Whether the API maps or reads should also be discussed, or
> whether it's allowed to heuristically choose.
>

In three posts, a simple "we should have a way to read an entire file into
a string without going through file opening and specific read operations"
idea metastasized into dealing with questions of memory ownership/file size
querying (views cannot own memory, so if you make a view-based API, you
must provide that memory), memory mapped files, and other issues that the
original idea was not intending to deal with.

This is a very simple idea: there should be a one-line way to read the
entirety of a text file into a string. That's it.

Just consider your suggested API:

std::string_view read_file(const std::filesystem::path &pth, ...);

That returns a `string_view`. Well, who owns that memory? `string_view` is
non-modifiable, so you can't pass one in to be overwritten. And even if you
change it to `span<char>` taken as a parameter, the user wouldn't know how
much storage to allocate for the file. So now, they have to add a second
line to ask what size the file is, and a third line to allocate the storage
to be read into:

auto file_size = std::filesystem::file_size(path);
std::string str(file_size);
read_file(str, path, ...);

I'm going to ignore that there are no checks to ensure that `file_size`
does not exceed the available size for a `std::string`. I'm going to ignore
that there is the possibility that some other program changes the size of
that file between steps 1 and 3. And I'm going to ignore that line 2
needlessly value-initializes a bunch of storage I'm about to overwrite.
I'll just take this solution at face-value.

If reading a file into a container is going to take 3 separate lines, how
is this an improvement over the status quo, as cited by the OP? The *whole
point* of this exercise is to make the currently semi-complex task of
reading a file into a string into the one-liner function of the sort that
many other standard libraries give you.

As for memory mapped files, `read_file` couldn't return a `string_view` of
a memory-mapped file either. Someone needs to be able to close this file.
We're not C programmers; we're not going to have some kind of hidden global
object that represents the memory mapped file, as well as a `close_file`
function to pair with `read_file`. So this function would have to return
some object that represents the memory mapped file:

std::mem_mapped_file read_file(const std::filesystem::path &pth, ...);

Is `mem_mapped_file` convertible to a `std::string`? I hope not; too many
things are convertible to/from `string` as it is. So now it would either be
a range (and thus you could use the `basic_string` range constructor) or it
would have to have a member function to convert it to a string. Thus, you
would perform the desired operation as:

auto file = std::read_file(path, ...).as_string();

But wait; if it returns a memory-mapped file, why is the function called
"read_file"? It's not really *reading* anything; you're just getting a
memory-mapped file that's opened for reading. In fact, isn't the behavior
of this "read_file" function suspiciously like what you would expect to
find in a constructor? Shouldn't `mem_mapped_file`'s constructor just take
a path and the assorted other parameters?

So now we have:

auto file = std::mem_mapped_file(path, ...).as_string();

Well, at least this version is one-line. But it's still overcomplicated and
far from intuitive.

Overcomplications like this are what makes C++ so frustrating at times.
There's this pressure to make *everything* expose all of the possible
knobs, because if it doesn't, then somebody somewhere might not use it.
This is what leads to APIs like `to/from_chars` not working with
`string_view`, because if it required that, then somebody might not want to
use it.

I'm not saying that those conversations and ideas aren't worthwhile. Having
an API for dealing with memory-mapped files would be great; I'd love to see
a good, use-able `mem_mapped_file` type.

But that doesn't mean we shouldn't have a function that genuinely reads a
file into a genuine, user-provided container. I agree that it shouldn't be
slaved to `std::string`; it should take the container type as a template
parameter, with `std::string` used as a default. But it should do a single,
simple thing: read the file into the container.

template<ContiguousRange container, typename ...Args>
  requires /*container must have insertion functions that take character
ranges and be constructible from the forwarded arguments.*/
container read_file(const std::filesystem::path &pth, EncodingOrWhatever enc
, Args... &&args);

No memory mapping (not as anything other than an implementation detail), no
questions of who owns what, nada. Just take the contents of a file and dump
it into a type called `container`.

Keep the simple things simple and all that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d1994c3-9215-4112-bbb9-874e5173412d%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, December 22, 2018 at 7:21:50 PM UTC-5, Thiago=
 Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, 2=
2 December 2018 14:15:52 -02 Richard Hodges wrote:
<br>&gt; Of course &quot;load file into string&quot; isn&#39;t really what =
you want here. All you
<br>&gt; need to do is &quot;map file into memory&quot;. The file just happ=
ens to have text in
<br>&gt; it.
<br>&gt;=20
<br>&gt; Native memory mapping is trivial with mmap on unix-like systems. (=
I use a
<br>&gt; simple wrapper around mmap and fopen). A slighly more abstract and
<br>&gt; cross-platform interface is available in the boost interprocess li=
brary.
<br>
<br>He may actually need &quot;read into std::string&quot; if the sink API =
that he needs to=20
<br>work with takes a std::string.
<br>
<br>But it&#39;s actually far more likely that the API takes something else=
.. In fact,=20
<br>in the OP&#39;s scenario, a C API like OpenGL will not be dealing in te=
rms of=20
<br>std::string. It&#39;s trivial to create a std::string out of a std::str=
ing_view or=20
<br>std::array_view or equivalent, so that should be the direction this pro=
posal=20
<br>should take. Whether the API maps or reads should also be discussed, or=
=20
<br>whether it&#39;s allowed to heuristically choose.
<br></blockquote><div><br></div><div>In three posts, a simple &quot;we shou=
ld have a way to read an entire file into a string without going through fi=
le opening and specific read operations&quot; idea metastasized into dealin=
g with questions of memory ownership/file size querying (views cannot own m=
emory, so if you make a view-based API, you must provide that memory), memo=
ry mapped files, and other issues that the original idea was not intending =
to deal with.</div><div><br></div><div>This is a very simple idea: there sh=
ould be a one-line way to read the entirety of a text file into a string. T=
hat&#39;s it.<br></div><div><br></div><div>Just consider your suggested API=
:</div><div><br></div><div><div style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">string_view read_file</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">filesystem</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">path </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">pth</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: #660;" class=3D"s=
tyled-by-prettify">...);</span></div></code></div></div><div><br></div><div=
>That returns a `string_view`. Well, who owns that memory? `string_view` is=
 non-modifiable, so you can&#39;t pass one in to be overwritten. And even i=
f you change it to `span&lt;char&gt;` taken as a parameter, the user wouldn=
&#39;t know how much storage to allocate for the file. So now, they have to=
 add a second line to ask what size the file is, and a third line to alloca=
te the storage to be read into:</div><div><br></div><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprin=
t"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> file_size </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">filesystem</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">file_size</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
path</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> str</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">file_size</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>read_file</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">str</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> path</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: #660;" class=3D"styled-by-prettify">...);</span></div></c=
ode></div><div><span class=3D"mw-geshi cpp source-cpp"></span></div><div><s=
pan class=3D"mw-geshi cpp source-cpp"><br></span></div><div><span class=3D"=
mw-geshi cpp source-cpp">I&#39;m going to ignore that there are no checks t=
o ensure that `file_size` does not exceed the available size for a `std::st=
ring`. I&#39;m going to ignore that there is the possibility that some othe=
r program changes the size of that file between steps 1 and 3. And I&#39;m =
going to ignore that line 2 needlessly value-initializes a bunch of storage=
 I&#39;m about to overwrite. I&#39;ll just take this solution at face-value=
..</span><br></div><div><br></div><div>If reading a file into a container is=
 going to take 3 separate lines, how is this an improvement over the status=
 quo, as cited by the OP? The <i>whole point</i> of this exercise is to mak=
e the currently semi-complex task of reading a file into a string into the =
one-liner function of the sort that many other standard libraries give you.=
<br></div><div><br></div><div>As for memory mapped files, `read_file` could=
n&#39;t return a `string_view` of a memory-mapped file either. Someone need=
s to be able to close this file. We&#39;re not C programmers; we&#39;re not=
 going to have some kind of hidden global object that represents the memory=
 mapped file, as well as a `close_file` function to pair with `read_file`. =
So this function would have to return some object that represents the memor=
y mapped file:</div><div><br></div><div><div style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">mem_mapped_file read_file</span><span style=3D"color: #660=
;" 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"s=
tyled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">filesystem</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">pat=
h </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">pth</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=
: #660;" class=3D"styled-by-prettify">...);</span></div></code></div><br></=
div><div></div><div>Is `mem_mapped_file` convertible to a `std::string`? I =
hope not; too many things are convertible to/from `string` as it is. So now=
 it would either be a range (and thus you could use the `basic_string` rang=
e constructor) or it would have to have a member function to convert it to =
a string. Thus, you would perform the desired operation as:</div><div><br><=
/div><div><div style=3D"background-color: rgb(250, 250, 250); border-color:=
 rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap:=
 break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fi=
le </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">read_file</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">path</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"style=
d-by-prettify">...).</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">as_string</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">();</span></div></code></div></div><div><br></div><div>But wait; i=
f it returns a memory-mapped file, why is the function called &quot;read_fi=
le&quot;? It&#39;s not really <i>reading</i> anything; you&#39;re just gett=
ing a memory-mapped file that&#39;s opened for reading. In fact, isn&#39;t =
the behavior of this &quot;read_file&quot; function suspiciously like what =
you would expect to find in a constructor? Shouldn&#39;t `mem_mapped_file`&=
#39;s constructor just take a path and the assorted other parameters?</div>=
<div><br></div><div>So now we have:</div><div><br></div><div><div style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"p=
rettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> file </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">mem_mapped_file</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">path</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">...)=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">as_string=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span>=
</div></code></div></div><div><br></div><div>Well, at least this version is=
 one-line. But it&#39;s still overcomplicated and far from intuitive.<br></=
div><div><br></div><div>Overcomplications like this are what makes C++ so f=
rustrating at times. There&#39;s this pressure to make <i>everything</i> ex=
pose all of the possible knobs, because if it doesn&#39;t, then somebody so=
mewhere might not use it. This is what leads to APIs like `to/from_chars` n=
ot working with `string_view`, because if it required that, then somebody m=
ight not want to use it.<br></div><div><br></div><div>I&#39;m not saying th=
at those conversations and ideas aren&#39;t worthwhile. Having an API for d=
ealing with memory-mapped files would be great; I&#39;d love to see a good,=
 use-able `mem_mapped_file` type.<br></div><div><br></div><div>But that doe=
sn&#39;t mean we shouldn&#39;t have a function that genuinely reads a file =
into a genuine, user-provided container. I agree that it shouldn&#39;t be s=
laved to `std::string`; it should take the container type as a template par=
ameter, with `std::string` used as a default. But it should do a single, si=
mple thing: read the file into the container.</div><div><br></div><div styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">ContiguousRange</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> container</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=
: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">...</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Args</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0 requires </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">/*container must have insertion functions that take chara=
cter ranges and be constructible from the forwarded arguments.*/</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>container read_fi=
le</span><span style=3D"color: #660;" 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"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">filesystem</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">path </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">pth</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: #606;" class=3D"styled-by-prettify">Enco=
dingOrWhatever</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> enc</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">args</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span></div></code></div><div><br>No memory m=
apping (not as anything other than an implementation detail), no questions =
of who owns what, nada. Just take the contents of a file and dump it into a=
 type called `container`.<br></div><div><br></div><div>Keep the simple thin=
gs simple and all that.</div></div>

<p></p>

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

------=_Part_1107_1042729583.1545542331863--

------=_Part_1106_895220184.1545542331862--

.

 > needing a function to read a text file into a std::string

Will this do?

#include <fstream>
#include <sstream>

   std::ifstream src(filename, std::ios::binary);
   std::ostringstream dst;
   dst << src.rdbuf() << std::ends;
   const std::string& s = dst.str();

Robin
--
Robin Rowe
323-535-0952 mobile
Beverly Hills, California

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/922bfdba-e4df-6cc0-4efa-9b8540df0bcc%40gmail.com.

.

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

On Sun, 23 Dec 2018 at 05:18, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Saturday, December 22, 2018 at 7:21:50 PM UTC-5, Thiago Macieira wrote:
>>
>> On Saturday, 22 December 2018 14:15:52 -02 Richard Hodges wrote:
>> > Of course "load file into string" isn't really what you want here. All
>> you
>> > need to do is "map file into memory". The file just happens to have
>> text in
>> > it.
>> >
>> > Native memory mapping is trivial with mmap on unix-like systems. (I use
>> a
>> > simple wrapper around mmap and fopen). A slighly more abstract and
>> > cross-platform interface is available in the boost interprocess
>> library.
>>
>> He may actually need "read into std::string" if the sink API that he
>> needs to
>> work with takes a std::string.
>>
>> But it's actually far more likely that the API takes something else. In
>> fact,
>> in the OP's scenario, a C API like OpenGL will not be dealing in terms of
>> std::string. It's trivial to create a std::string out of a
>> std::string_view or
>> std::array_view or equivalent, so that should be the direction this
>> proposal
>> should take. Whether the API maps or reads should also be discussed, or
>> whether it's allowed to heuristically choose.
>>
>
> In three posts, a simple "we should have a way to read an entire file into
> a string without going through file opening and specific read operations"
> idea metastasized into dealing with questions of memory ownership/file size
> querying (views cannot own memory, so if you make a view-based API, you
> must provide that memory), memory mapped files, and other issues that the
> original idea was not intending to deal with.
>
> This is a very simple idea: there should be a one-line way to read the
> entirety of a text file into a string. That's it.
>
> Just consider your suggested API:
>
> std::string_view read_file(const std::filesystem::path &pth, ...);
>
> That returns a `string_view`. Well, who owns that memory? `string_view` is
> non-modifiable, so you can't pass one in to be overwritten. And even if you
> change it to `span<char>` taken as a parameter, the user wouldn't know how
> much storage to allocate for the file. So now, they have to add a second
> line to ask what size the file is, and a third line to allocate the storage
> to be read into:
>
> auto file_size = std::filesystem::file_size(path);
> std::string str(file_size);
> read_file(str, path, ...);
>
> I'm going to ignore that there are no checks to ensure that `file_size`
> does not exceed the available size for a `std::string`. I'm going to ignore
> that there is the possibility that some other program changes the size of
> that file between steps 1 and 3. And I'm going to ignore that line 2
> needlessly value-initializes a bunch of storage I'm about to overwrite.
> I'll just take this solution at face-value.
>
> If reading a file into a container is going to take 3 separate lines, how
> is this an improvement over the status quo, as cited by the OP? The *whole
> point* of this exercise is to make the currently semi-complex task of
> reading a file into a string into the one-liner function of the sort that
> many other standard libraries give you.
>
> As for memory mapped files, `read_file` couldn't return a `string_view` of
> a memory-mapped file either. Someone needs to be able to close this file.
> We're not C programmers; we're not going to have some kind of hidden global
> object that represents the memory mapped file, as well as a `close_file`
> function to pair with `read_file`. So this function would have to return
> some object that represents the memory mapped file:
>
> std::mem_mapped_file read_file(const std::filesystem::path &pth, ...);
>
> Is `mem_mapped_file` convertible to a `std::string`? I hope not; too many
> things are convertible to/from `string` as it is. So now it would either be
> a range (and thus you could use the `basic_string` range constructor) or it
> would have to have a member function to convert it to a string. Thus, you
> would perform the desired operation as:
>
> auto file = std::read_file(path, ...).as_string();
>
> But wait; if it returns a memory-mapped file, why is the function called
> "read_file"? It's not really *reading* anything; you're just getting a
> memory-mapped file that's opened for reading. In fact, isn't the behavior
> of this "read_file" function suspiciously like what you would expect to
> find in a constructor? Shouldn't `mem_mapped_file`'s constructor just take
> a path and the assorted other parameters?
>
> So now we have:
>
> auto file = std::mem_mapped_file(path, ...).as_string();
>
> Well, at least this version is one-line. But it's still overcomplicated
> and far from intuitive.
>
> Overcomplications like this are what makes C++ so frustrating at times.
> There's this pressure to make *everything* expose all of the possible
> knobs, because if it doesn't, then somebody somewhere might not use it.
> This is what leads to APIs like `to/from_chars` not working with
> `string_view`, because if it required that, then somebody might not want to
> use it.
>
> I'm not saying that those conversations and ideas aren't worthwhile.
> Having an API for dealing with memory-mapped files would be great; I'd love
> to see a good, use-able `mem_mapped_file` type.
>
> But that doesn't mean we shouldn't have a function that genuinely reads a
> file into a genuine, user-provided container. I agree that it shouldn't be
> slaved to `std::string`; it should take the container type as a template
> parameter, with `std::string` used as a default. But it should do a single,
> simple thing: read the file into the container.
>
> template<ContiguousRange container, typename ...Args>
>   requires /*container must have insertion functions that take character
> ranges and be constructible from the forwarded arguments.*/
> container read_file(const std::filesystem::path &pth, EncodingOrWhatever
> enc, Args... &&args);
>
> No memory mapping (not as anything other than an implementation detail),
> no questions of who owns what, nada. Just take the contents of a file and
> dump it into a type called `container`.
>
> Keep the simple things simple and all that.
>

I wholeheartedly agree that simple things should be simple, and out of
frustration at the "messyness" of the current state of the standard
library, I knocked up a little wrapper library for projects I work on (and
probably should publish somewhere so clever people can improve it).

it provides interfaces like this:

using namespace wrapper::posix;        // provides RAII posix-like concepts
like file descriptors and strings owned by the OS

my_program.load(mmap(open("robot.glsl", readonly)));   // where...

my_program.load(      // is loading a range of chars into my glsl program
  posix::mmap(        // is returning a RAII memory-mapping object, which
is automatically a range of chars by default
    posix::open(      // is returning an RAII wrapper around the concept of
a file descriptor
      "robot.glsl",   //   which can be contructed with strings, paths or
other descriptors (implying ::dup())
      posix::readonly // a constexpr value expressing a type so we can
select read-only versions of wrappers at compile time
     )));

There is no reason why the intent above could not be expressed as:

my_program.load(open("robot.glsl"));

Here, the same is achieved but it is nowhere near as efficient or pleasing.
A file-descriptor is inherently a range. By default it's read-only.

or for people are comfortable with script languages...

using namespace std::literals;
using namespace wrapper::posix;
using namespace wrapper::perllike;

auto prog = ""s < open("robot.glsl");
my_program.load(prog);

// could also be written as:
auto prog2 = std::string() < open("...");

In  my view, this scheme offers a number of advantages:

* It's powerful
* it's simple
* it reads like script, or a narrative, which in my view is a *good thing*,
and something that std c++ fails at.

Writing a file from a string is another common operation which is difficult
in standard c++

auto s = get_string();
s > "temp.txt"_write_file;     // overwrite
s >> "temp.txt"_write_file;    // append

Disclaimer: I happen to like writing c++ that looks like script. My
reasoning is that if a reader can determine my intent from reading the
high-level narrative, without worrying about begin(), end(), <templates>
and trivial lifetime management, he's more likely to make a productive
change and less likely to make a mistake.

https://godbolt.org/z/E25HvH

All error handling is by exceptions. The reason here is that if you're
doing synchronous I/O, the cost of a thrown exception is irrelevant.

--
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d1994c3-9215-4112-bbb9-874e5173412d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d1994c3-9215-4112-bbb9-874e5173412d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>


--
Richard Hodges
hodges.r@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212 (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYY2i0_%3DEQK0fLGB1ou_%3D-HJRxiWvVH_UA-qh-XtDZOTg%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, 23 Dec 2018 at 0=
5:18, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr">On Saturday, December 22, 2018 at 7:21:50 PM UTC-5, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On S=
aturday, 22 December 2018 14:15:52 -02 Richard Hodges wrote:
<br>&gt; Of course &quot;load file into string&quot; isn&#39;t really what =
you want here. All you
<br>&gt; need to do is &quot;map file into memory&quot;. The file just happ=
ens to have text in
<br>&gt; it.
<br>&gt;=20
<br>&gt; Native memory mapping is trivial with mmap on unix-like systems. (=
I use a
<br>&gt; simple wrapper around mmap and fopen). A slighly more abstract and
<br>&gt; cross-platform interface is available in the boost interprocess li=
brary.
<br>
<br>He may actually need &quot;read into std::string&quot; if the sink API =
that he needs to=20
<br>work with takes a std::string.
<br>
<br>But it&#39;s actually far more likely that the API takes something else=
.. In fact,=20
<br>in the OP&#39;s scenario, a C API like OpenGL will not be dealing in te=
rms of=20
<br>std::string. It&#39;s trivial to create a std::string out of a std::str=
ing_view or=20
<br>std::array_view or equivalent, so that should be the direction this pro=
posal=20
<br>should take. Whether the API maps or reads should also be discussed, or=
=20
<br>whether it&#39;s allowed to heuristically choose.
<br></blockquote><div><br></div><div>In three posts, a simple &quot;we shou=
ld have a way to read an entire file into a string without going through fi=
le opening and specific read operations&quot; idea metastasized into dealin=
g with questions of memory ownership/file size querying (views cannot own m=
emory, so if you make a view-based API, you must provide that memory), memo=
ry mapped files, and other issues that the original idea was not intending =
to deal with.</div><div><br></div><div>This is a very simple idea: there sh=
ould be a one-line way to read the entirety of a text file into a string. T=
hat&#39;s it.<br></div><div><br></div><div>Just consider your suggested API=
:</div><div><br></div><div><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px" class=3D=
"gmail-m_-7252362298278134510prettyprint"><code class=3D"gmail-m_-725236229=
8278134510prettyprint"><div class=3D"gmail-m_-7252362298278134510subprettyp=
rint"><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-725236229827813451=
0styled-by-prettify">std</span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-7252362298278134510styled-by-prettify">::</span><span style=3D=
"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify"=
>string_view read_file</span><span style=3D"color:rgb(102,102,0)" class=3D"=
gmail-m_-7252362298278134510styled-by-prettify">(</span><span style=3D"colo=
r:rgb(0,0,136)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">co=
nst</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-72523622982781=
34510styled-by-prettify"> std</span><span style=3D"color:rgb(102,102,0)" cl=
ass=3D"gmail-m_-7252362298278134510styled-by-prettify">::</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-pretti=
fy">filesystem</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_=
-7252362298278134510styled-by-prettify">::</span><span style=3D"color:rgb(0=
,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">path </span=
><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510=
styled-by-prettify">&amp;</span><span style=3D"color:rgb(0,0,0)" class=3D"g=
mail-m_-7252362298278134510styled-by-prettify">pth</span><span style=3D"col=
or:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify"=
>,</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-725236229827813=
4510styled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-7252362298278134510styled-by-prettify">...);</span></div></cod=
e></div></div><div><br></div><div>That returns a `string_view`. Well, who o=
wns that memory? `string_view` is non-modifiable, so you can&#39;t pass one=
 in to be overwritten. And even if you change it to `span&lt;char&gt;` take=
n as a parameter, the user wouldn&#39;t know how much storage to allocate f=
or the file. So now, they have to add a second line to ask what size the fi=
le is, and a third line to allocate the storage to be read into:</div><div>=
<br></div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px" class=3D"gmail-m_-7252362=
298278134510prettyprint"><code class=3D"gmail-m_-7252362298278134510prettyp=
rint"><div class=3D"gmail-m_-7252362298278134510subprettyprint"><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_-7252362298278134510styled-by-pret=
tify">auto</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362=
298278134510styled-by-prettify"> file_size </span><span style=3D"color:rgb(=
102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">=3D</s=
pan><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510s=
tyled-by-prettify"> std</span><span style=3D"color:rgb(102,102,0)" class=3D=
"gmail-m_-7252362298278134510styled-by-prettify">::</span><span style=3D"co=
lor:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">fi=
lesystem</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-72523=
62298278134510styled-by-prettify">::</span><span style=3D"color:rgb(0,0,0)"=
 class=3D"gmail-m_-7252362298278134510styled-by-prettify">file_size</span><=
span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510st=
yled-by-prettify">(</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m=
_-7252362298278134510styled-by-prettify">path</span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">);</=
span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510=
styled-by-prettify"><br>std</span><span style=3D"color:rgb(102,102,0)" clas=
s=3D"gmail-m_-7252362298278134510styled-by-prettify">::</span><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_-7252362298278134510styled-by-pret=
tify">string</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-72523=
62298278134510styled-by-prettify"> str</span><span style=3D"color:rgb(102,1=
02,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">(</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-b=
y-prettify">file_size</span><span style=3D"color:rgb(102,102,0)" class=3D"g=
mail-m_-7252362298278134510styled-by-prettify">);</span><span style=3D"colo=
r:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify"><br>=
read_file</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252=
362298278134510styled-by-prettify">(</span><span style=3D"color:rgb(0,0,0)"=
 class=3D"gmail-m_-7252362298278134510styled-by-prettify">str</span><span s=
tyle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-b=
y-prettify">,</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252=
362298278134510styled-by-prettify"> path</span><span style=3D"color:rgb(102=
,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">,</span><=
span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled=
-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m=
_-7252362298278134510styled-by-prettify">...);</span></div></code></div><di=
v><span class=3D"gmail-m_-7252362298278134510mw-geshi gmail-m_-725236229827=
8134510cpp gmail-m_-7252362298278134510source-cpp"></span></div><div><span =
class=3D"gmail-m_-7252362298278134510mw-geshi gmail-m_-7252362298278134510c=
pp gmail-m_-7252362298278134510source-cpp"><br></span></div><div><span clas=
s=3D"gmail-m_-7252362298278134510mw-geshi gmail-m_-7252362298278134510cpp g=
mail-m_-7252362298278134510source-cpp">I&#39;m going to ignore that there a=
re no checks to ensure that `file_size` does not exceed the available size =
for a `std::string`. I&#39;m going to ignore that there is the possibility =
that some other program changes the size of that file between steps 1 and 3=
.. And I&#39;m going to ignore that line 2 needlessly value-initializes a bu=
nch of storage I&#39;m about to overwrite. I&#39;ll just take this solution=
 at face-value.</span><br></div><div><br></div><div>If reading a file into =
a container is going to take 3 separate lines, how is this an improvement o=
ver the status quo, as cited by the OP? The <i>whole point</i> of this exer=
cise is to make the currently semi-complex task of reading a file into a st=
ring into the one-liner function of the sort that many other standard libra=
ries give you.<br></div><div><br></div><div>As for memory mapped files, `re=
ad_file` couldn&#39;t return a `string_view` of a memory-mapped file either=
.. Someone needs to be able to close this file. We&#39;re not C programmers;=
 we&#39;re not going to have some kind of hidden global object that represe=
nts the memory mapped file, as well as a `close_file` function to pair with=
 `read_file`. So this function would have to return some object that repres=
ents the memory mapped file:</div><div><br></div><div><div style=3D"backgro=
und-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid=
;border-width:1px" class=3D"gmail-m_-7252362298278134510prettyprint"><code =
class=3D"gmail-m_-7252362298278134510prettyprint"><div class=3D"gmail-m_-72=
52362298278134510subprettyprint"><span style=3D"color:rgb(0,0,0)" class=3D"=
gmail-m_-7252362298278134510styled-by-prettify">std</span><span style=3D"co=
lor:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify=
">::</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278=
134510styled-by-prettify">mem_mapped_file read_file</span><span style=3D"co=
lor:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify=
">(</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-725236229827=
8134510styled-by-prettify">const</span><span style=3D"color:rgb(0,0,0)" cla=
ss=3D"gmail-m_-7252362298278134510styled-by-prettify"> std</span><span styl=
e=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-p=
rettify">::</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-725236=
2298278134510styled-by-prettify">filesystem</span><span style=3D"color:rgb(=
102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">::</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510st=
yled-by-prettify">path </span><span style=3D"color:rgb(102,102,0)" class=3D=
"gmail-m_-7252362298278134510styled-by-prettify">&amp;</span><span style=3D=
"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify"=
>pth</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-725236229=
8278134510styled-by-prettify">,</span><span style=3D"color:rgb(0,0,0)" clas=
s=3D"gmail-m_-7252362298278134510styled-by-prettify"> </span><span style=3D=
"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prett=
ify">...);</span></div></code></div><br></div><div></div><div>Is `mem_mappe=
d_file` convertible to a `std::string`? I hope not; too many things are con=
vertible to/from `string` as it is. So now it would either be a range (and =
thus you could use the `basic_string` range constructor) or it would have t=
o have a member function to convert it to a string. Thus, you would perform=
 the desired operation as:</div><div><br></div><div><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px" class=3D"gmail-m_-7252362298278134510prettyprint"><code cl=
ass=3D"gmail-m_-7252362298278134510prettyprint"><div class=3D"gmail-m_-7252=
362298278134510subprettyprint"><span style=3D"color:rgb(0,0,136)" class=3D"=
gmail-m_-7252362298278134510styled-by-prettify">auto</span><span style=3D"c=
olor:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify"> =
file </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-72523622=
98278134510styled-by-prettify">=3D</span><span style=3D"color:rgb(0,0,0)" c=
lass=3D"gmail-m_-7252362298278134510styled-by-prettify"> std</span><span st=
yle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by=
-prettify">::</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252=
362298278134510styled-by-prettify">read_file</span><span style=3D"color:rgb=
(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">(</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510st=
yled-by-prettify">path</span><span style=3D"color:rgb(102,102,0)" class=3D"=
gmail-m_-7252362298278134510styled-by-prettify">,</span><span style=3D"colo=
r:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify"> </s=
pan><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134=
510styled-by-prettify">...).</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-7252362298278134510styled-by-prettify">as_string</span><span s=
tyle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-b=
y-prettify">();</span></div></code></div></div><div><br></div><div>But wait=
; if it returns a memory-mapped file, why is the function called &quot;read=
_file&quot;? It&#39;s not really <i>reading</i> anything; you&#39;re just g=
etting a memory-mapped file that&#39;s opened for reading. In fact, isn&#39=
;t the behavior of this &quot;read_file&quot; function suspiciously like wh=
at you would expect to find in a constructor? Shouldn&#39;t `mem_mapped_fil=
e`&#39;s constructor just take a path and the assorted other parameters?</d=
iv><div><br></div><div>So now we have:</div><div><br></div><div><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px" class=3D"gmail-m_-7252362298278134510prettypr=
int"><code class=3D"gmail-m_-7252362298278134510prettyprint"><div class=3D"=
gmail-m_-7252362298278134510subprettyprint"><span style=3D"color:rgb(0,0,13=
6)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">auto</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-b=
y-prettify"> file </span><span style=3D"color:rgb(102,102,0)" class=3D"gmai=
l-m_-7252362298278134510styled-by-prettify">=3D</span><span style=3D"color:=
rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify"> std</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-725236229827813=
4510styled-by-prettify">::</span><span style=3D"color:rgb(0,0,0)" class=3D"=
gmail-m_-7252362298278134510styled-by-prettify">mem_mapped_file</span><span=
 style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled=
-by-prettify">(</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-72=
52362298278134510styled-by-prettify">path</span><span style=3D"color:rgb(10=
2,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">,</span>=
<span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510style=
d-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_-7252362298278134510styled-by-prettify">...).</span><span style=3D"color:=
rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">as_str=
ing</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298=
278134510styled-by-prettify">();</span></div></code></div></div><div><br></=
div><div>Well, at least this version is one-line. But it&#39;s still overco=
mplicated and far from intuitive.<br></div><div><br></div><div>Overcomplica=
tions like this are what makes C++ so frustrating at times. There&#39;s thi=
s pressure to make <i>everything</i> expose all of the possible knobs, beca=
use if it doesn&#39;t, then somebody somewhere might not use it. This is wh=
at leads to APIs like `to/from_chars` not working with `string_view`, becau=
se if it required that, then somebody might not want to use it.<br></div><d=
iv><br></div><div>I&#39;m not saying that those conversations and ideas are=
n&#39;t worthwhile. Having an API for dealing with memory-mapped files woul=
d be great; I&#39;d love to see a good, use-able `mem_mapped_file` type.<br=
></div><div><br></div><div>But that doesn&#39;t mean we shouldn&#39;t have =
a function that genuinely reads a file into a genuine, user-provided contai=
ner. I agree that it shouldn&#39;t be slaved to `std::string`; it should ta=
ke the container type as a template parameter, with `std::string` used as a=
 default. But it should do a single, simple thing: read the file into the c=
ontainer.</div><div><br></div><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px" class=
=3D"gmail-m_-7252362298278134510prettyprint"><code class=3D"gmail-m_-725236=
2298278134510prettyprint"><div class=3D"gmail-m_-7252362298278134510subpret=
typrint"><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-7252362298278=
134510styled-by-prettify">template</span><span style=3D"color:rgb(102,102,0=
)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">&lt;</span><spa=
n style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-7252362298278134510style=
d-by-prettify">ContiguousRange</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-7252362298278134510styled-by-prettify"> container</span><span =
style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-=
by-prettify">,</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-725=
2362298278134510styled-by-prettify"> </span><span style=3D"color:rgb(0,0,13=
6)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">typename</span=
><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styl=
ed-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail=
-m_-7252362298278134510styled-by-prettify">...</span><span style=3D"color:r=
gb(102,0,102)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">Arg=
s</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-725236229827=
8134510styled-by-prettify">&gt;</span><span style=3D"color:rgb(0,0,0)" clas=
s=3D"gmail-m_-7252362298278134510styled-by-prettify"><br>=C2=A0 requires </=
span><span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-72523622982781345=
10styled-by-prettify">/*container must have insertion functions that take c=
haracter ranges and be constructible from the forwarded arguments.*/</span>=
<span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510style=
d-by-prettify"><br>container read_file</span><span style=3D"color:rgb(102,1=
02,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">(</span><sp=
an style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-7252362298278134510styled=
-by-prettify">const</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m=
_-7252362298278134510styled-by-prettify"> std</span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">::</=
span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510=
styled-by-prettify">filesystem</span><span style=3D"color:rgb(102,102,0)" c=
lass=3D"gmail-m_-7252362298278134510styled-by-prettify">::</span><span styl=
e=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prett=
ify">path </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-725=
2362298278134510styled-by-prettify">&amp;</span><span style=3D"color:rgb(0,=
0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">pth</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7252362298278134510sty=
led-by-prettify">,</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_=
-7252362298278134510styled-by-prettify"> </span><span style=3D"color:rgb(10=
2,0,102)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">Encoding=
OrWhatever</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362=
298278134510styled-by-prettify"> enc</span><span style=3D"color:rgb(102,102=
,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">,</span><span=
 style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-=
prettify"> </span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-72=
52362298278134510styled-by-prettify">Args</span><span style=3D"color:rgb(10=
2,102,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify">...</spa=
n><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510sty=
led-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmai=
l-m_-7252362298278134510styled-by-prettify">&amp;&amp;</span><span style=3D=
"color:rgb(0,0,0)" class=3D"gmail-m_-7252362298278134510styled-by-prettify"=
>args</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-72523622=
98278134510styled-by-prettify">);</span></div></code></div><div><br>No memo=
ry mapping (not as anything other than an implementation detail), no questi=
ons of who owns what, nada. Just take the contents of a file and dump it in=
to a type called `container`.<br></div><div><br></div><div>Keep the simple =
things simple and all that.</div></div></blockquote><div><br></div><div>I w=
holeheartedly agree that simple things should be simple, and out of frustra=
tion at the &quot;messyness&quot; of the current state of the standard libr=
ary, I knocked up a little wrapper library for projects I work on (and prob=
ably should publish somewhere so clever people can improve it).</div><div><=
br></div><div>it provides interfaces like this:</div><div><br></div><div><d=
iv><span style=3D"font-family:monospace,monospace">using namespace wrapper:=
:posix;=C2=A0 =C2=A0 =C2=A0 =C2=A0 // provides RAII posix-like concepts lik=
e file descriptors and strings owned by the OS</span><br></div><br class=3D=
"gmail-Apple-interchange-newline"></div><div><font face=3D"monospace, monos=
pace">my_program.load(mmap(open(&quot;robot.glsl&quot;, readonly)));=C2=A0 =
=C2=A0// where...</font></div><div><font face=3D"monospace, monospace"><br>=
</font></div><div><div><font face=3D"monospace, monospace">my_program.load(=
=C2=A0 =C2=A0 =C2=A0 // is loading a range of chars into my glsl program</f=
ont></div><div><font face=3D"monospace, monospace">=C2=A0 posix::mmap(=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // is returning a RAII memory-mapping object, whic=
h is automatically a range of chars by default</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 posix::open(=C2=A0 =C2=A0 =C2=A0 //=
 is returning an RAII wrapper around the concept of a file descriptor</font=
></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 &quot;=
robot.glsl&quot;,=C2=A0 =C2=A0//=C2=A0 =C2=A0which can be contructed with s=
trings, paths or other descriptors (implying ::dup())=C2=A0</font></div><di=
v><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 posix::readonly =
// a constexpr value expressing a type so we can select read-only versions =
of wrappers at compile time</font></div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 =C2=A0)));=C2=A0=C2=A0</font></div><font face=3D"monosp=
ace, monospace"><br class=3D"gmail-Apple-interchange-newline"></font></div>=
<div>There is no reason why the intent above could not be expressed as:</di=
v><div><br></div><div><div><font face=3D"monospace, monospace">my_program.l=
oad(open(&quot;robot.glsl&quot;));</font></div><br class=3D"gmail-Apple-int=
erchange-newline"></div><div>Here, the same is achieved but it is nowhere n=
ear as efficient or pleasing. A file-descriptor is inherently a range. By d=
efault it&#39;s read-only.</div><br class=3D"gmail-Apple-interchange-newlin=
e"><div><font face=3D"arial, helvetica, sans-serif">or for people are comfo=
rtable with script languages...</font></div><div><font face=3D"monospace, m=
onospace"><br></font></div><div><div><font face=3D"monospace, monospace">us=
ing namespace std::literals;</font></div><div><span style=3D"font-family:mo=
nospace,monospace">using namespace wrapper::posix;</span></div><div><span s=
tyle=3D"font-family:monospace,monospace">using namespace wrapper::perllike;=
</span><br class=3D"gmail-Apple-interchange-newline"></div><br class=3D"gma=
il-Apple-interchange-newline"></div><div><span style=3D"font-family:monospa=
ce,monospace">auto prog =3D &quot;&quot;s &lt; open(&quot;robot.glsl&quot;)=
;</span><br></div><div><span style=3D"font-family:monospace,monospace">my_p=
rogram.load(prog);</span></div><br class=3D"gmail-Apple-interchange-newline=
"><div><span style=3D"font-family:monospace,monospace">// could also be wri=
tten as:</span></div><div><span style=3D"font-family:monospace,monospace">a=
uto prog2 =3D std::string() &lt; open(&quot;...&quot;);</span></div><div><b=
r></div><div>In=C2=A0 my view, this scheme offers a number of advantages:</=
div><div><br></div><div>* It&#39;s powerful</div><div>* it&#39;s simple</di=
v><div>* it reads like script, or a narrative, which in my view is a *good =
thing*, and something that std c++ fails at.</div><div><br></div><div>Writi=
ng a file from a string is another common operation which is difficult in s=
tandard c++</div><div><br></div><div><span style=3D"font-family:monospace,m=
onospace">auto s =3D get_string();</span><br></div><div><div><font face=3D"=
monospace, monospace">s &gt; &quot;temp.txt&quot;_write_file;=C2=A0 =C2=A0 =
=C2=A0// overwrite</font></div><div><font face=3D"monospace, monospace">s &=
gt;&gt; &quot;temp.txt&quot;</font><span style=3D"font-family:monospace,mon=
ospace">_write_file</span><font face=3D"monospace, monospace">;=C2=A0 =C2=
=A0 // append</font></div><br class=3D"gmail-Apple-interchange-newline"></d=
iv><div>Disclaimer: I happen to like writing c++ that looks like script. My=
 reasoning is that if a reader can determine my intent from reading the hig=
h-level narrative, without worrying about begin(), end(), &lt;templates&gt;=
 and trivial lifetime management, he&#39;s more likely to make a productive=
 change and less likely to make a mistake.</div><div>=C2=A0</div><div><a hr=
ef=3D"https://godbolt.org/z/E25HvH">https://godbolt.org/z/E25HvH</a><br></d=
iv><div><br></div><div>All error handling is by exceptions. The reason here=
 is that if you&#39;re doing synchronous I/O, the cost of a thrown exceptio=
n is irrelevant.</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2d1994c3-9215-4112-bbb9-874e5173412d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d1994c3-9215-=
4112-bbb9-874e5173412d%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr">Richard Hodges<div><a href=3D"m=
ailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a></div><di=
v>office: +442032898513</div><div>home: +376841522</div><div>mobile:=C2=A0+=
376380212 (this will be *expensive* outside Andorra!)</div><div>skype: madm=
ongo</div><div>facebook: hodges.r</div><div><br></div></div></div></div></d=
iv></div>

<p></p>

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

--000000000000d0cee5057daaec86--

.

------=_Part_1098_1986670617.1545621541622
Content-Type: multipart/alternative;
 boundary="----=_Part_1099_1604141019.1545621541623"

------=_Part_1099_1604141019.1545621541623
Content-Type: text/plain; charset="UTF-8"


>
> I worked with OpenGL and OpenCL in the last years and I oftenly found
> myself needing a function to read a text file into a std::string variable
> (i.e. to read a shader or kernel program source file and pass it to
> OpenCL/OpenGL). While there are some good solutions on stackoverflow
> <https://stackoverflow.com/a/2602060> I wonder why there is no such
> facility in the standard library or at least in the Boost libraries.
>
> http://wg21.link/P1031 *Low level file i/o* provides something close.

mapped<char> contents(file({}, "textfile.txt"));

mapped<char> refines span<char>, so it auto-participates in Ranges, STL etc.

If you don't want to guard reads for segfault, you can pass in
flag::prefault, it'll fail to map the file.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ddcb3c11-beb6-4de9-87bf-e737b52fda55%40isocpp.org.

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I worked with=
 OpenGL and OpenCL in the last years and I oftenly found myself needing a f=
unction to read a text file into a std::string variable (i.e. to read a sha=
der or kernel program source file and pass it to OpenCL/OpenGL). While ther=
e are some good solutions on <a href=3D"https://stackoverflow.com/a/2602060=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fa%2F2602060\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFJ03Jg_mLDWc8OYxNTulj9juPzjQ&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps=
%3A%2F%2Fstackoverflow.com%2Fa%2F2602060\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFJ03Jg_mLDWc8OYxNTulj9juPzjQ&#39;;return true;">stackoverflow</a>=C2=
=A0I wonder why there is no such facility in the standard library or at lea=
st in the Boost libraries.<div><br></div></div></blockquote><div>http://wg2=
1.link/P1031 <i>Low level file i/o</i>=C2=A0provides something close.</div>=
<div><br></div><div><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; overflow-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">mapped</span><span style=3D"color: #080;" class=3D"styled-by-pr=
ettify">&lt;char&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> contents</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" 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><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&quot;textfile.txt&qu=
ot;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</sp=
an></div></code></div><br></div><div>mapped&lt;char&gt; refines span&lt;cha=
r&gt;, so it auto-participates in Ranges, STL etc.</div><div><br></div><div=
>If you don&#39;t want to guard reads for segfault, you can pass in flag::p=
refault, it&#39;ll fail to map the file.</div><div><br></div><div>Niall</di=
v><div><br></div>

<p></p>

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

------=_Part_1099_1604141019.1545621541623--

------=_Part_1098_1986670617.1545621541622--

.

------=_Part_1141_1154292134.1545622386537
Content-Type: multipart/alternative;
 boundary="----=_Part_1142_606710422.1545622386537"

------=_Part_1142_606710422.1545622386537
Content-Type: text/plain; charset="UTF-8"


>
> Here, the same is achieved but it is nowhere near as efficient or
> pleasing. A file-descriptor is inherently a range. By default it's
> read-only.
>

This is incorrect. A file is a collection of extents. A range of ranges.
Not a single range. It is very important to get this right, else sparse and
compressed files have terrible performance and disk volumes don't work
right when addressed as files.


> All error handling is by exceptions. The reason here is that if you're
> doing synchronous I/O, the cost of a thrown exception is irrelevant.
>

This is incorrect. The kernel can return failure from an i/o operation in
less than 100 ns. A dynamic C++ exception throw and catch on table based EH
is around 1000 ns. Therefore choosing C++ exception throws to handle errors
from the filesystem is an incorrect choice, and it is why P1031 LLFIO does
not use dynamic exception throws.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e0b9628a-66c3-4c64-a28f-8227461cf17f%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Here,=
 the same is achieved but it is nowhere near as efficient or pleasing. A fi=
le-descriptor is inherently a range. By default it&#39;s read-only.</div></=
div></div></div></div></blockquote><div><br></div><div>This is incorrect. A=
 file is a collection of extents. A range of ranges. Not a single range. It=
 is very important to get this right, else sparse and compressed files have=
 terrible performance and disk volumes don&#39;t work right when addressed =
as files.</div><div>=C2=A0</div><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 dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_qu=
ote"><div>All error handling is by exceptions. The reason here is that if y=
ou&#39;re doing synchronous I/O, the cost of a thrown exception is irreleva=
nt.</div></div></div></div></div></blockquote><div><br></div><div>This is i=
ncorrect. The kernel can return failure from an i/o operation in less than =
100 ns. A dynamic C++ exception throw and catch on table based EH is around=
 1000 ns. Therefore choosing C++ exception throws to handle errors from the=
 filesystem is an incorrect choice, and it is why P1031 LLFIO does not use =
dynamic exception throws.</div><div><br></div><div>Niall</div><div><br></di=
v></div>

<p></p>

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

------=_Part_1142_606710422.1545622386537--

------=_Part_1141_1154292134.1545622386537--

.

--0000000000008b3c3a057dbca9d3
Content-Type: text/plain; charset="UTF-8"

On Mon, 24 Dec 2018 at 10:33, Niall Douglas <nialldouglas14@gmail.com>
wrote:

> Here, the same is achieved but it is nowhere near as efficient or
>> pleasing. A file-descriptor is inherently a range. By default it's
>> read-only.
>>
>
> This is incorrect. A file is a collection of extents. A range of ranges.
> Not a single range. It is very important to get this right, else sparse and
> compressed files have terrible performance and disk volumes don't work
> right when addressed as files.
>

Strictly, yes. But this impacts on complexity and the aim of my library is
to "keep simple things simple". A file containing structured data can (in
my world) be modeled by a different type.

In my experience, I'm doing one of two things with files:
1. open them occasionally and read/interpret  the entire contents
 - this is modeled correctly by "a file is a range of chars" and
performance is never an issue.
- this use case I think lends itself to exceptions since it's something
we're doing once, and readability trumps performance of rare failure cases
in this scenario.

2. something more complex, involving locks, memory mapping and some form of
structured data.
-  This is no longer a simple thing and is very likely to be
performance-critical. In which case a composable set of building blocks
with performant detection of *temporary* error conditions is just what I
would be looking for.

The key on error handling for me is whether we intend to recover from an
error, fix the environment and keep going, or whether the condition is
fatal to the operation. If it's fatal to the program or current operation,
an exception is fine (for me) because the loss of a few micro-seconds
before I log the error and bail is not an issue.

If the error is "the file does not yet exist", and this condition can be
recovered by the program, then this is not a candidate for exceptions -
because it's not exceptional - It's an expected code path.



>
>
>> All error handling is by exceptions. The reason here is that if you're
>> doing synchronous I/O, the cost of a thrown exception is irrelevant.
>>
>
> This is incorrect. The kernel can return failure from an i/o operation in
> less than 100 ns. A dynamic C++ exception throw and catch on table based EH
> is around 1000 ns. Therefore choosing C++ exception throws to handle errors
> from the filesystem is an incorrect choice, and it is why P1031 LLFIO does
> not use dynamic exception throws.
>
>
See above. I think it depends on the context. If the 'exception' was an
expected code path, it's not an exception. In this case it's a condition
(which can be modeled with a code or a variant type).

As we constantly keep teaching new programmers, exceptions are for truly
exceptional occurrences, not temporary error conditions. These happen so
rarely that performance is not the key. I would argue that correctness and
readability of code are more important considerations. Littering code with
error checks is something we rightly stopped doing 30 years ago. It
destroys readability.

Unreadable code get re-written, usually in java or c#, because people
wrongly assume that this removes the hard choices. Once that happens, all
discussions on performance and whether or not to use exceptions are
completely moot.



> Niall
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e0b9628a-66c3-4c64-a28f-8227461cf17f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e0b9628a-66c3-4c64-a28f-8227461cf17f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>


--
Richard Hodges
hodges.r@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212 (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYsk_N9Fr7zbRBPYKCOwsVqbnxjwuzemOLByAWzTibCWw%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">On Mon, 24 Dec 2018 at 10:33, Niall Douglas &lt;<a href=3D=
"mailto:nialldouglas14@gmail.com">nialldouglas14@gmail.com</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=
=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Here, the same is=
 achieved but it is nowhere near as efficient or pleasing. A file-descripto=
r is inherently a range. By default it&#39;s read-only.</div></div></div></=
div></div></blockquote><div><br></div><div>This is incorrect. A file is a c=
ollection of extents. A range of ranges. Not a single range. It is very imp=
ortant to get this right, else sparse and compressed files have terrible pe=
rformance and disk volumes don&#39;t work right when addressed as files.</d=
iv></div></blockquote><div><br></div><div>Strictly, yes. But this impacts o=
n complexity and the aim of my library is to &quot;keep simple things simpl=
e&quot;. A file containing structured data can (in my world) be modeled by =
a different type.=C2=A0</div><div><br></div><div>In my experience, I&#39;m =
doing one of two things with files:</div><div>1. open them occasionally and=
 read/interpret=C2=A0 the entire contents</div><div>=C2=A0- this is modeled=
 correctly by &quot;a file is a range of chars&quot; and performance is nev=
er an issue.=C2=A0</div><div>- this use case I think lends itself to except=
ions since it&#39;s something we&#39;re doing once, and readability trumps =
performance of rare failure cases in this scenario.</div><div><br></div><di=
v>2. something more complex, involving locks, memory mapping and some form =
of structured data.</div><div>-=C2=A0 This is no longer a simple thing and =
is very likely to be performance-critical. In which case a composable set o=
f building blocks with performant detection of *temporary* error conditions=
 is just what I would be looking for.</div><div><br></div><div>The key on e=
rror handling for me is whether we intend to recover from an error, fix the=
 environment and keep going, or whether the condition is fatal to the opera=
tion. If it&#39;s fatal to the program or current operation, an exception i=
s fine (for me) because the loss of a few micro-seconds before I log the er=
ror and bail is not an issue.=C2=A0</div><div><br></div><div>If the error i=
s &quot;the file does not yet exist&quot;, and this condition can be recove=
red by the program, then this is not a candidate for exceptions - because i=
t&#39;s not exceptional - It&#39;s an expected code path.</div><div><br></d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_=
quote"><div>All error handling is by exceptions. The reason here is that if=
 you&#39;re doing synchronous I/O, the cost of a thrown exception is irrele=
vant.</div></div></div></div></div></blockquote><div><br></div><div>This is=
 incorrect. The kernel can return failure from an i/o operation in less tha=
n 100 ns. A dynamic C++ exception throw and catch on table based EH is arou=
nd 1000 ns. Therefore choosing C++ exception throws to handle errors from t=
he filesystem is an incorrect choice, and it is why P1031 LLFIO does not us=
e dynamic exception throws.</div><div><br></div></div></blockquote><div><br=
></div><div>See above. I think it depends on the context. If the &#39;excep=
tion&#39; was an expected code path, it&#39;s not an exception. In this cas=
e it&#39;s a condition (which can be modeled with a code or a variant type)=
..</div><div><br></div><div>As we constantly keep teaching new programmers, =
exceptions are for truly exceptional occurrences, not temporary error condi=
tions. These happen so rarely that performance is not the key. I would argu=
e that correctness and readability of code are more important consideration=
s. Littering code with error checks is something we rightly stopped doing 3=
0 years ago. It destroys readability.</div><div><br></div><div>Unreadable c=
ode get re-written, usually in java or c#, because people wrongly assume th=
at this removes the hard choices. Once that happens, all discussions on per=
formance and whether or not to use exceptions are completely moot.</div><di=
v><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div></div><div>Niall</div><div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e0b9628a-66c3-4c64-a28f-8227461cf17f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e0b9628a-66c3-=
4c64-a28f-8227461cf17f%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr">Richard Hodges<div><a href=3D"m=
ailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a></div><di=
v>office: +442032898513</div><div>home: +376841522</div><div>mobile:=C2=A0+=
376380212 (this will be *expensive* outside Andorra!)</div><div>skype: madm=
ongo</div><div>facebook: hodges.r</div><div><br></div></div></div></div>

<p></p>

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

--0000000000008b3c3a057dbca9d3--

.

------=_Part_1055_2023310531.1545629938430
Content-Type: multipart/alternative;
 boundary="----=_Part_1056_2093421795.1545629938430"

------=_Part_1056_2093421795.1545629938430
Content-Type: text/plain; charset="UTF-8"


>
>
>> This is incorrect. A file is a collection of extents. A range of ranges.
>> Not a single range. It is very important to get this right, else sparse and
>> compressed files have terrible performance and disk volumes don't work
>> right when addressed as files.
>>
>
> Strictly, yes. But this impacts on complexity and the aim of my library is
> to "keep simple things simple". A file containing structured data can (in
> my world) be modeled by a different type.
>

There is no structured data involved here. Files are composed of zero or
more extents of data with non-overlapping offsets and lengths. Either you
map reality into the C++ program, or you map make believe. Simplification
never involves make believe. Simplification involves more powerful
abstraction, which is not make believe.

Committee members are working on the more powerful abstractions you seek.
There may be a nascent experimental i/o study group coming. There may be an
elsewhere memory study group coming. We are looking for generic ways for
generic code to discover i/o facilities. The correct design allows
serialisation to be placed between e.g. Ranges and storage, or for Ranges
to work with chunks of raw bytes. Ranges should not need to know any more
than a generalised Concept mapping for i/o discovery. i/o providers should
not need to do anything but match the Concepts for their discovery. It
should all be *seamless* at the high level, but allow dipping into
customising the mechanics where needed at the low level.

We are targeting C++ 23, but expect slippage to C++ 26. But we're
definitely on it.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a6e36fd8-1e43-427f-847f-f7788d4b9e37%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div><br></div><div>This is incorrect. A file is a c=
ollection of extents. A range of ranges. Not a single range. It is very imp=
ortant to get this right, else sparse and compressed files have terrible pe=
rformance and disk volumes don&#39;t work right when addressed as files.</d=
iv></div></blockquote><div><br></div><div>Strictly, yes. But this impacts o=
n complexity and the aim of my library is to &quot;keep simple things simpl=
e&quot;. A file containing structured data can (in my world) be modeled by =
a different type.=C2=A0</div></div></div></blockquote><div><br></div><div>T=
here is no structured data involved here. Files are composed of zero or mor=
e extents of data with non-overlapping offsets and lengths. Either you map =
reality into the C++ program, or you map make believe. Simplification never=
 involves make believe. Simplification involves more powerful abstraction, =
which is not make believe.</div><div><br></div><div>Committee members are w=
orking on the more powerful abstractions you seek. There may be a nascent e=
xperimental i/o study group coming. There may be an elsewhere memory study =
group coming. We are looking for generic ways for generic code to discover =
i/o facilities. The correct design allows serialisation to be placed betwee=
n e.g. Ranges and storage, or for Ranges to work with chunks of raw bytes. =
Ranges should not need to know any more than a generalised Concept mapping =
for i/o discovery. i/o providers should not need to do anything but match t=
he Concepts for their discovery. It should all be <i>seamless</i>=C2=A0at t=
he high level, but allow dipping into customising the mechanics where neede=
d at the low level.</div><div><br></div><div>We are targeting C++ 23, but e=
xpect slippage to C++ 26. But we&#39;re definitely on it.</div><div><br></d=
iv><div>Niall</div><div><br></div></div>

<p></p>

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

------=_Part_1056_2093421795.1545629938430--

------=_Part_1055_2023310531.1545629938430--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">&gt;&nbsp;<span style=3D"line-height: initial;">As we constantl=
y keep teaching new programmers, exceptions are for truly exceptional occur=
rences</span></div><div style=3D"width: 100%; font-size: initial; font-fami=
ly: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); =
text-align: initial; background-color: rgb(255, 255, 255);"><span style=3D"=
line-height: initial;"><br></span></div><div style=3D"width: 100%; font-siz=
e: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; colo=
r: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 2=
55);"><span style=3D"line-height: initial;">I wish we'd all stop =E2=80=8Et=
eaching that. It's catchy, but I'm not sure there really is any strong argu=
ments to back it up.</span></div><div style=3D"width: 100%; font-size: init=
ial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(=
31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><=
span style=3D"line-height: initial;"><br></span></div><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);"><span style=3D"line-height: initial;">I'd say exception=
s are for transactional-style programming. User selects a file to load, it =
either does or doesn't. Give them a bit of feedback (file not found, file c=
orrupt, etc) and be back in the state from before we tried.</span></div><di=
v style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pr=
o', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; b=
ackground-color: rgb(255, 255, 255);"><span style=3D"line-height: initial;"=
><br></span></div>                                                         =
                                                                           =
 <div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slat=
e Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initia=
l; background-color: rgb(255, 255, 255);"><br style=3D"display:initial"></d=
iv>                                                                        =
                                                                           =
                                                <div style=3D"font-size: in=
itial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rg=
b(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"=
>Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Dev=
ice</div>                                                                  =
                                                                           =
                                     <table width=3D"100%" style=3D"backgro=
und-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D=
"font-size: initial; text-align: initial; background-color: rgb(255, 255, 2=
55);">                           <div style=3D"border-style: solid none non=
e; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3p=
t 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10=
pt;">  <div><b>From: </b>Richard Hodges</div><div><b>Sent: </b>Sunday, Dece=
mber 23, 2018 11:02 PM</div><div><b>To: </b>std-proposals@isocpp.org</div><=
div><b>Reply To: </b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re:=
 [std-proposals] Read text file to string</div></div></td></tr></tbody></ta=
ble><div style=3D"border-style: solid none none; border-top-color: rgb(186,=
 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial;=
 background-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalConte=
nt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Mon, 24 Dec 2018 at 10:33, Niall Dougl=
as &lt;<a href=3D"mailto:nialldouglas14@gmail.com">nialldouglas14@gmail.com=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=
Here, the same is achieved but it is nowhere near as efficient or pleasing.=
 A file-descriptor is inherently a range. By default it's read-only.</div><=
/div></div></div></div></blockquote><div><br></div><div>This is incorrect. =
A file is a collection of extents. A range of ranges. Not a single range. I=
t is very important to get this right, else sparse and compressed files hav=
e terrible performance and disk volumes don't work right when addressed as =
files.</div></div></blockquote><div><br></div><div>Strictly, yes. But this =
impacts on complexity and the aim of my library is to "keep simple things s=
imple". A file containing structured data can (in my world) be modeled by a=
 different type.&nbsp;</div><div><br></div><div>In my experience, I'm doing=
 one of two things with files:</div><div>1. open them occasionally and read=
/interpret&nbsp; the entire contents</div><div>&nbsp;- this is modeled corr=
ectly by "a file is a range of chars" and performance is never an issue.&nb=
sp;</div><div>- this use case I think lends itself to exceptions since it's=
 something we're doing once, and readability trumps performance of rare fai=
lure cases in this scenario.</div><div><br></div><div>2. something more com=
plex, involving locks, memory mapping and some form of structured data.</di=
v><div>-&nbsp; This is no longer a simple thing and is very likely to be pe=
rformance-critical. In which case a composable set of building blocks with =
performant detection of *temporary* error conditions is just what I would b=
e looking for.</div><div><br></div><div>The key on error handling for me is=
 whether we intend to recover from an error, fix the environment and keep g=
oing, or whether the condition is fatal to the operation. If it's fatal to =
the program or current operation, an exception is fine (for me) because the=
 loss of a few micro-seconds before I log the error and bail is not an issu=
e.&nbsp;</div><div><br></div><div>If the error is "the file does not yet ex=
ist", and this condition can be recovered by the program, then this is not =
a candidate for exceptions - because it's not exceptional - It's an expecte=
d code path.</div><div><br></div><div>&nbsp;</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div class=3D"gmail_quote"><div>All error handling is by exceptio=
ns. The reason here is that if you're doing synchronous I/O, the cost of a =
thrown exception is irrelevant.</div></div></div></div></div></blockquote><=
div><br></div><div>This is incorrect. The kernel can return failure from an=
 i/o operation in less than 100 ns. A dynamic C++ exception throw and catch=
 on table based EH is around 1000 ns. Therefore choosing C++ exception thro=
ws to handle errors from the filesystem is an incorrect choice, and it is w=
hy P1031 LLFIO does not use dynamic exception throws.</div><div><br></div><=
/div></blockquote><div><br></div><div>See above. I think it depends on the =
context. If the 'exception' was an expected code path, it's not an exceptio=
n. In this case it's a condition (which can be modeled with a code or a var=
iant type).</div><div><br></div><div>As we constantly keep teaching new pro=
grammers, exceptions are for truly exceptional occurrences, not temporary e=
rror conditions. These happen so rarely that performance is not the key. I =
would argue that correctness and readability of code are more important con=
siderations. Littering code with error checks is something we rightly stopp=
ed doing 30 years ago. It destroys readability.</div><div><br></div><div>Un=
readable code get re-written, usually in java or c#, because people wrongly=
 assume that this removes the hard choices. Once that happens, all discussi=
ons on performance and whether or not to use exceptions are completely moot=
..</div><div><br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div></div><div>Niall</div><div><br></div></=
div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e0b9628a-66c3-4c64-a28f-8227461cf17f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e0b9628a-66c3-=
4c64-a28f-8227461cf17f%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr">Richard Hodges<div><a href=3D"m=
ailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a></div><di=
v>office: +442032898513</div><div>home: +376841522</div><div>mobile:&nbsp;+=
376380212 (this will be *expensive* outside Andorra!)</div><div>skype: madm=
ongo</div><div>facebook: hodges.r</div><div><br></div></div></div></div>

<p></p>

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

<p></p>

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

.

------=_Part_1624_815289450.1545858807460
Content-Type: multipart/alternative;
 boundary="----=_Part_1625_128825260.1545858807461"

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



Wow, I did not expect these many answers! Thank you for your comments!

=20

I got a little stuck on the memory mapped file approach, as it seems to be=
=20
efficient and to solve my initial problem. The sink types of my API=20
functions (glShaderSource and clCreateProgramWithSource) are somewhat=20
char*, so mapping the source file to memory and passing the pointer would=
=20
suffice.

However, I wish for something I can write in a single line of code. When=20
using Boost.Interprocess, I need to create an instance of file_mapping and=
=20
an instance of mapped_region. And I have to make sure those objects stick=
=20
around as long as the pointer to the mapped region is used. So it requires=
=20
a bit of code to type (and remember until my next project) and a dependency=
=20
to Boost.


I really like Nicol Bolas=E2=80=99 discussion on such an API. I agree that =
a one=20
liner to read a file into a container should be part of the standard=20
library. It is simple, especially for inexperienced users, and sufficient=
=20
in most use cases. Andrew Tomazos also mentioned, he has seen such a=20
facility in multiple libraries.

I wonder what SG20 (education) thinks about such APIs; If simple and=20
beginner friendly functions for such common tasks could coexist with more=
=20
elaborated and expert friendly features to accomplish the same thing. I.e.=
=20
beginners could use a read_file() function, while experts may consult Niall=
=20
Douglas=E2=80=99 low level file IO (P1031).


I did a small benchmark of a few ways to read a text file, here are the=20
results (Windows x64 VS2017):


Small text file (2.5KiB):
assign_istreambuf_iterator_NL      96742 ns      95215 ns
ifstream_read_NL                   75292 ns      74986 ns
ostringstream_rdbuf                82388 ns      81961 ns
map                                73077 ns      73239 ns
map_and_string_ctor                78213 ns      78474 ns
map_and_string_NL                  88650 ns      88937 ns


Big text file (5.5MiB):
assign_istreambuf_iterator_NL   70779588 ns   71022727 ns
ifstream_read_NL                11756074 ns   11718750 ns
ostringstream_rdbuf             58163906 ns   58238636 ns
map                                75854 ns      74986 ns
map_and_string_ctor              9346960 ns    9375000 ns
map_and_string_NL               18884060 ns   19003378 ns


source: http://quick-bench.com/LkoCPOfsYFQO6v2ppbfd9NVCK2Y


All tests with _NL at the end correctly transform \r\n to \n, which might=
=20
matter for some applications. ostringstream_rdbuf is the shortest to type=
=20
(thank you Robin Rowe). We can see, that there is no big difference if the=
=20
files are rather small (e.g. shader code files, some config files, etc.).=
=20
Just mapping is clearly faster when the file is larger, but if we actually=
=20
touch the memory (i.e. by creating a std::string), it only wins by 25% over=
=20
ifstream read. In case we want to normalize the line endings to \n,=20
ifstream read seems to be the fastest.=20


So my question is, is there a place in the standard library for a read_file=
=20
like the one Nicol Bolas suggested?


template<ContiguousRange container, typename ...Args>
>   requires /*container must have insertion functions that take character=
=20
> ranges and be constructible from the forwarded arguments.*/
> container read_file(const std::filesystem::path &pth, EncodingOrWhatever
>  enc, Args... &&args);


=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d3b474d9-8a9b-4192-b2cb-64f5921115f1%40isocpp.or=
g.

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

<div dir=3D"ltr"><p class=3D"MsoNormal">Wow, I did not expect these many an=
swers! Thank you for your
comments!<o:p></o:p></p><p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p><p clas=
s=3D"MsoNormal">I got a little stuck on the memory mapped file approach, as
it seems to be efficient and to solve my initial problem. The sink types of=
 my
API functions (glShaderSource and clCreateProgramWithSource) are somewhat c=
har*,
so mapping the source file to memory and passing the pointer would suffice.=
<o:p></o:p></p><p class=3D"MsoNormal">However, I wish for something I can w=
rite in a single line
of code. When using Boost.Interprocess, I need to create an instance of fil=
e_mapping
and an instance of mapped_region. And I have to make sure those objects sti=
ck
around as long as the pointer to the mapped region is used. So it requires =
a
bit of code to type (and remember until my next project) and a dependency t=
o Boost.<o:p></o:p></p><p class=3D"MsoNormal"><br></p><p class=3D"MsoNormal=
">I really like Nicol Bolas=E2=80=99 discussion on such an API. I
agree that a one liner to read a file into a container should be part of th=
e
standard library. It is simple, especially for inexperienced users, and suf=
ficient
in most use cases. Andrew Tomazos also mentioned, he has seen such a facili=
ty
in multiple libraries.<o:p></o:p></p><p class=3D"MsoNormal">I wonder what S=
G20 (education) thinks about such APIs; If simple
and beginner friendly functions for such common tasks could coexist with mo=
re
elaborated and expert friendly features to accomplish the same thing. I.e.
beginners could use a read_file() function, while experts may consult Niall
Douglas=E2=80=99 low level file IO (P1031).<o:p></o:p></p><p class=3D"MsoNo=
rmal"><br></p><p class=3D"MsoNormal">I did a small benchmark of a few ways =
to read a text file,
here are the results (Windows x64 VS2017):<o:p></o:p></p><p class=3D"MsoNor=
mal"><br></p><p class=3D"MsoNormal">Small text file (2.5KiB):</p><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #000;" class=3D"styled-by-prettify">assign_istreambuf_=
iterator_NL =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">96742</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> ns =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">95215</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> ns<br>ifstream_read_NL =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">75292</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> ns =C2=A0 =C2=A0 =C2=A0</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">74986</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> ns<br>ostringstream_rdbuf =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">82388</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> ns =C2=A0 =C2=A0 =C2=A0</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">81961</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> ns<br>map =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">73077</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> n=
s =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">73239</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> ns<br>map_and_string_ctor =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">78213</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
ns =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"styled-=
by-prettify">78474</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> ns<br>map_and_string_NL =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">88650</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> ns =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">88937</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> ns</span></div></code></div><p class=3D"MsoNormal"><br></p><=
p class=3D"MsoNormal">Big text file (5.5MiB):<o:p></o:p></p><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: br=
eak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: #000;" class=3D"styled-by-prettify">assign_istreambuf_itera=
tor_NL =C2=A0 </span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">70779588</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> ns =C2=A0 </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">71022727</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> ns<br>ifstream_read_NL =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1175=
6074</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ns =
=C2=A0 </span><span style=3D"color: #066;" class=3D"styled-by-prettify">117=
18750</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ns<b=
r>ostringstream_rdbuf =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">58163906</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> ns =C2=A0 </span><span=
 style=3D"color: #066;" class=3D"styled-by-prettify">58238636</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> ns<br>map =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"styled=
-by-prettify">75854</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> ns =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">74986</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> ns<br>map_and_string_ctor =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">9346960</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> ns =C2=A0 =C2=A0</span><span style=3D"color: #066;" class=3D"styled=
-by-prettify">9375000</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> ns<br>map_and_string_NL =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>18884060</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
ns =C2=A0 </span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
19003378</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> n=
s</span></div></code></div><p class=3D"MsoNormal"><br></p><p class=3D"MsoNo=
rmal">source:=C2=A0<a href=3D"http://quick-bench.com/LkoCPOfsYFQO6v2ppbfd9N=
VCK2Y">http://quick-bench.com/LkoCPOfsYFQO6v2ppbfd9NVCK2Y</a></p><p class=
=3D"MsoNormal"><br></p><p class=3D"MsoNormal">All tests with _NL at the end=
 correctly transform \r\n to \n, which might matter for some applications. =
ostringstream_rdbuf is the shortest to type (thank you Robin
Rowe). We can see, that there is no big difference
if the files are rather small (e.g. shader code files, some config files, e=
tc.).
Just mapping is clearly faster when the file is larger, but if we actually
touch the memory (i.e. by creating a std::string), it only wins by 25% over
ifstream read. In case we want to normalize the line endings to \n, ifstrea=
m
read seems to be the fastest. <o:p></o:p></p><p class=3D"MsoNormal"><br></p=
><p class=3D"MsoNormal">So my question is, is there a place in the standard=
 library for
a read_file like the one Nicol Bolas suggested?<o:p></o:p></p><p class=3D"M=
soNormal"><br></p><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"=
><span style=3D"font-family: monospace; background-color: rgb(250, 250, 250=
); color: rgb(0, 0, 136);">template</span><span style=3D"font-family: monos=
pace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">&lt;<=
/span><span style=3D"font-family: monospace; background-color: rgb(250, 250=
, 250); color: rgb(102, 0, 102);">ContiguousRange</span><span style=3D"font=
-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, =
0);">=C2=A0container</span><span style=3D"font-family: monospace; backgroun=
d-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">,</span><span style=
=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: rg=
b(0, 0, 0);">=C2=A0</span><span style=3D"font-family: monospace; background=
-color: rgb(250, 250, 250); color: rgb(0, 0, 136);">typename</span><span st=
yle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color:=
 rgb(0, 0, 0);">=C2=A0</span><span style=3D"font-family: monospace; backgro=
und-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">...</span><span st=
yle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color:=
 rgb(102, 0, 102);">Args</span><span style=3D"font-family: monospace; backg=
round-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">&gt;<br></span><=
span style=3D"font-family: monospace; background-color: rgb(250, 250, 250);=
 color: rgb(0, 0, 0);">=C2=A0 requires=C2=A0</span><span style=3D"font-fami=
ly: monospace; background-color: rgb(250, 250, 250); color: rgb(136, 0, 0);=
">/*container must have insertion functions that take character ranges and =
be constructible from the forwarded arguments.*/<br></span><span style=3D"f=
ont-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0, =
0, 0);">container read_file</span><span style=3D"font-family: monospace; ba=
ckground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">(</span><span=
 style=3D"font-family: monospace; background-color: rgb(250, 250, 250); col=
or: rgb(0, 0, 136);">const</span><span style=3D"font-family: monospace; bac=
kground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0std</span><s=
pan style=3D"font-family: monospace; background-color: rgb(250, 250, 250); =
color: rgb(102, 102, 0);">::</span><span style=3D"font-family: monospace; b=
ackground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">filesystem</span=
><span style=3D"font-family: monospace; background-color: rgb(250, 250, 250=
); color: rgb(102, 102, 0);">::</span><span style=3D"font-family: monospace=
; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">path=C2=A0</s=
pan><span style=3D"font-family: monospace; background-color: rgb(250, 250, =
250); color: rgb(102, 102, 0);">&amp;</span><span style=3D"font-family: mon=
ospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">pth</sp=
an><span style=3D"font-family: monospace; background-color: rgb(250, 250, 2=
50); color: rgb(102, 102, 0);">,</span><span style=3D"font-family: monospac=
e; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0</span=
><span style=3D"font-family: monospace; background-color: rgb(250, 250, 250=
); color: rgb(102, 0, 102);">EncodingOrWhatever</span><span style=3D"font-f=
amily: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0)=
;">=C2=A0enc</span><span style=3D"font-family: monospace; background-color:=
 rgb(250, 250, 250); color: rgb(102, 102, 0);">,</span><span style=3D"font-=
family: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0, 0=
);">=C2=A0</span><span style=3D"font-family: monospace; background-color: r=
gb(250, 250, 250); color: rgb(102, 0, 102);">Args</span><span style=3D"font=
-family: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 1=
02, 0);">...</span><span style=3D"font-family: monospace; background-color:=
 rgb(250, 250, 250); color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"font=
-family: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 1=
02, 0);">&amp;&amp;</span><span style=3D"font-family: monospace; background=
-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">args</span><span style=3D=
"font-family: monospace; background-color: rgb(250, 250, 250); color: rgb(1=
02, 102, 0);">);</span></blockquote><p class=3D"MsoNormal"><br></p><p class=
=3D"MsoNormal">

















































</p><p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p></div>

<p></p>

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

------=_Part_1625_128825260.1545858807461--

------=_Part_1624_815289450.1545858807460--

.

--000000000000893b6f057df37752
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 24, 2018 at 12:39 AM Niall Douglas <nialldouglas14@gmail.com>
wrote:

> Files are composed of zero or more extents of data with non-overlapping
> offsets and lengths.
>

That is an irrelevant implementation detail.  From the point of view of a
reader of a (non-device) file, it consists of a single stream of bytes.
The fact that the file system may be using some internal data structure to
represent long sequences of null bytes rather than the literal sequence
does not matter to the reader, in the same way that it does not matter if
the file system keeps the file compressed on disk and decompresses as
sections are read.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaH9qUBhF%2B4zv58De7LTJxZSefPuE3A%2BEYyVLC3PGgqzQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Dec 24, 2018 at 12:39 AM Niall Do=
uglas &lt;<a href=3D"mailto:nialldouglas14@gmail.com">nialldouglas14@gmail.=
com</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>Files are composed of zero =
or more extents of data with non-overlapping offsets and lengths.</div></di=
v></blockquote><div><br>That is an irrelevant implementation detail.=C2=A0 =
From the point of view of a reader of a (non-device) file, it consists of a=
 single stream of bytes.=C2=A0 The fact that the file system may be using s=
ome internal data structure to represent long sequences of null bytes rathe=
r than the literal sequence does not matter to the reader, in the same way =
that it does not matter if the file system keeps the file compressed on dis=
k and decompresses as sections are read.</div></div></div>

<p></p>

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

--000000000000893b6f057df37752--

.

------=_Part_1924_1873627066.1545886819943
Content-Type: multipart/alternative;
 boundary="----=_Part_1925_1265880954.1545886819943"

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


>
> I really like Nicol Bolas=E2=80=99 discussion on such an API. I agree tha=
t a one=20
> liner to read a file into a container should be part of the standard=20
> library. It is simple, especially for inexperienced users, and sufficient=
=20
> in most use cases. Andrew Tomazos also mentioned, he has seen such a=20
> facility in multiple libraries.
>
> I wonder what SG20 (education) thinks about such APIs; If simple and=20
> beginner friendly functions for such common tasks could coexist with more=
=20
> elaborated and expert friendly features to accomplish the same thing. I.e=
..=20
> beginners could use a read_file() function, while experts may consult Nia=
ll=20
> Douglas=E2=80=99 low level file IO (P1031).
>

I'm not keen on such a one-liner. If it came before committee I would argue=
=20
strenuously against it. The reason why is that memory mapped data is its=20
own storage, and performing a dynamic memory allocation and memory copy=20
when the mapped data can be used directly (e.g. via a string_view) is=20
sloppy and far too easy to do accidentally if it is a one liner.

Better in my opinion to separate the mapping step from the memory=20
allocation and memory copying step. So, two lines, one to do the map, the=
=20
other to construct a std::string from the mapped data.

This is what LLFIO's mapped<T> does, you get a span<T> onto the mapped=20
data. If you want to copy that into a std::string, you need to explicitly=
=20
do that by passing the mapped's begin() and end() to std::string. Of=20
course, in the real world, you should really just use the mapped data=20
directly by feeding it to a transforming Range view if you need to do CRLF=
=20
collapse etc.

(Incidentally, why in the current draft C++ standard does=20
basic_string_view<T> not implicitly construct from a span<T>? I can see no=
=20
good reason why it should not)

Niall

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/172e8224-0ea4-44a6-a7dd-ceffaa2bd7ab%40isocpp.or=
g.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><p class=
=3D"MsoNormal">I really like Nicol Bolas=E2=80=99 discussion on such an API=
.. I agree that a one liner to read a file into a container should be part o=
f the standard library. It is simple, especially for inexperienced users, a=
nd sufficient in most use cases. Andrew Tomazos also mentioned, he has seen=
 such a facility in multiple libraries.<br></p><p class=3D"MsoNormal">I won=
der what SG20 (education) thinks about such APIs; If simple and beginner fr=
iendly functions for such common tasks could coexist with more elaborated a=
nd expert friendly features to accomplish the same thing. I.e. beginners co=
uld use a read_file() function, while experts may consult Niall Douglas=E2=
=80=99 low level file IO (P1031).</p></div></blockquote><div><br></div><div=
>I&#39;m not keen on such a one-liner. If it came before committee I would =
argue strenuously against it. The reason why is that memory mapped data is =
its own storage, and performing a dynamic memory allocation and memory copy=
 when the mapped data can be used directly (e.g. via a string_view) is slop=
py and far too easy to do accidentally if it is a one liner.</div><div><br>=
</div><div>Better in my opinion to separate the mapping step from the memor=
y allocation and memory copying step. So, two lines, one to do the map, the=
 other to construct a std::string from the mapped data.</div><div><br></div=
><div>This is what LLFIO&#39;s mapped&lt;T&gt; does, you get a span&lt;T&gt=
; onto the mapped data. If you want to copy that into a std::string, you ne=
ed to explicitly do that by passing the mapped&#39;s begin() and end() to s=
td::string. Of course, in the real world, you should really just use the ma=
pped data directly by feeding it to a transforming Range view if you need t=
o do CRLF collapse etc.</div><div><br></div><div>(Incidentally, why in the =
current draft C++ standard does basic_string_view&lt;T&gt; not implicitly c=
onstruct from a span&lt;T&gt;? I can see no good reason why it should not)<=
/div><div><br></div><div>Niall</div></div>

<p></p>

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

------=_Part_1925_1265880954.1545886819943--

------=_Part_1924_1873627066.1545886819943--

.

------=_Part_1752_1165050782.1545887404074
Content-Type: multipart/alternative;
 boundary="----=_Part_1753_825156788.1545887404074"

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

On Thursday, December 27, 2018 at 12:00:20 AM UTC-5, Niall Douglas wrote:
>
> I really like Nicol Bolas=E2=80=99 discussion on such an API. I agree tha=
t a one=20
>> liner to read a file into a container should be part of the standard=20
>> library. It is simple, especially for inexperienced users, and sufficien=
t=20
>> in most use cases. Andrew Tomazos also mentioned, he has seen such a=20
>> facility in multiple libraries.
>>
>> I wonder what SG20 (education) thinks about such APIs; If simple and=20
>> beginner friendly functions for such common tasks could coexist with mor=
e=20
>> elaborated and expert friendly features to accomplish the same thing. I.=
e.=20
>> beginners could use a read_file() function, while experts may consult Ni=
all=20
>> Douglas=E2=80=99 low level file IO (P1031).
>>
>
> I'm not keen on such a one-liner. If it came before committee I would=20
> argue strenuously against it. The reason why is that memory mapped data i=
s=20
> its own storage, and performing a dynamic memory allocation and memory co=
py=20
> when the mapped data can be used directly (e.g. via a string_view) is=20
> sloppy and far too easy to do accidentally if it is a one liner.
>

APIs are made to fit the user; users should not be made to fit the API. The=
=20
people who use this function don't care about memory mapping, dynamic=20
memory allocations, memory copies or whatever. They want the file loaded=20
into a string, which they can use just like any other string in the=20
program. The specific details on what is the fastest way to accomplish this=
=20
is an irrelevant detail to them.

This is a high-level function for high-level needs.

Again, that doesn't mean we shouldn't have ways to do memory mapped files=
=20
and whatnot. But even if we have those techniques, we still want a simple=
=20
API to load a file into a string.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/258364bd-bf52-441a-9e1a-a5f311ad66a1%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, December 27, 2018 at 12:00:20 AM UTC-5, Niall=
 Douglas 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=
"><blockquote class=3D"gmail_quote" style=3D"border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><p class=3D"MsoNormal">I really=
 like Nicol Bolas=E2=80=99 discussion on such an API. I agree that a one li=
ner to read a file into a container should be part of the standard library.=
 It is simple, especially for inexperienced users, and sufficient in most u=
se cases. Andrew Tomazos also mentioned, he has seen such a facility in mul=
tiple libraries.<br></p><p class=3D"MsoNormal">I wonder what SG20 (educatio=
n) thinks about such APIs; If simple and beginner friendly functions for su=
ch common tasks could coexist with more elaborated and expert friendly feat=
ures to accomplish the same thing. I.e. beginners could use a read_file() f=
unction, while experts may consult Niall Douglas=E2=80=99 low level file IO=
 (P1031).</p></div></blockquote><div><br></div><div>I&#39;m not keen on suc=
h a one-liner. If it came before committee I would argue strenuously agains=
t it. The reason why is that memory mapped data is its own storage, and per=
forming a dynamic memory allocation and memory copy when the mapped data ca=
n be used directly (e.g. via a string_view) is sloppy and far too easy to d=
o accidentally if it is a one liner.</div></div></blockquote><div><br></div=
><div>APIs are made to fit the user; users should not be made to fit the AP=
I. The people who use this function don&#39;t care about memory mapping, dy=
namic memory allocations, memory copies or whatever. They want the file loa=
ded into a string, which they can use just like any other string in the pro=
gram. The specific details on what is the fastest way to accomplish this is=
 an irrelevant detail to them.</div><div><br></div><div></div><div>This is =
a high-level function for high-level needs.</div><div><br></div><div>Again,=
 that doesn&#39;t mean we shouldn&#39;t have ways to do memory mapped files=
 and whatnot. But even if we have those techniques, we still want a simple =
API to load a file into a string.</div><br></div>

<p></p>

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

------=_Part_1753_825156788.1545887404074--

------=_Part_1752_1165050782.1545887404074--

.

------=_Part_1706_1327023219.1545887713630
Content-Type: multipart/alternative;
 boundary="----=_Part_1707_473355917.1545887713630"

------=_Part_1707_473355917.1545887713630
Content-Type: text/plain; charset="UTF-8"


>
> Files are composed of zero or more extents of data with non-overlapping
>> offsets and lengths.
>>
>
> That is an irrelevant implementation detail.  From the point of view of a
> reader of a (non-device) file, it consists of a single stream of bytes.
> The fact that the file system may be using some internal data structure to
> represent long sequences of null bytes rather than the literal sequence
> does not matter to the reader, in the same way that it does not matter if
> the file system keeps the file compressed on disk and decompresses as
> sections are read.
>

This line of argument is very similar to scalar vs vector arithmetic: "From
the point of view of a performer of arithmetic, all math is scalar. It does
not matter if a vector unit is (inefficiently) used to perform scalar math".

And this is correct, if all you ever want to do is scalar math. Same goes
for a single stream of bytes. If you don't care about implementation
reality, sure, pretend your CPU can only ever do a single arithmetic
operation at a time.

But let's widen your horizons a bit. Don't write scalar math. Write math.
If it's unavoidably scalar, so be it. If the compiler can spot some
parallelisation in what you wrote for the target architecture, *far better*
 (usually).

Same goes for extents. Sure you can write your application assuming they
don't exist. Yet any filing system designed in the past twenty years has
them, same as how any recent CPU has a vector math unit which inefficiently
does your scalar math on request.

So don't write single extent code. Write extents-based code. It'll perform
no worse, and always much better, on discontiguous extent storage. Indeed
depending on the data, discontiguous extents may even lend well to
embarrassing parallelism.

A lot of people claim that single extent code is simpler. I've never bought
that argument. The least additional complexity is an additional for loop to
iterate the valid extents. That minor extra step turns days of execution
time to iterate simulated zero bytes into potentially seconds to iterate
the data actually stored where it's stored. It's a huge win. It ought to be
the default, and *is* the default in P1031 LLFIO.

(I'm still working on Eric to agree to have Ranges do the same, I think
I've nearly won that argument. For the Ranges end user, it's no difference
except a vast improvement in efficiency in sparsely stored files)

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5f4cb88f-5551-4083-a1d8-31e55238dae8%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div>Files are composed of zero or more extents of d=
ata with non-overlapping offsets and lengths.</div></div></blockquote><div>=
<br>That is an irrelevant implementation detail.=C2=A0 From the point of vi=
ew of a reader of a (non-device) file, it consists of a single stream of by=
tes.=C2=A0 The fact that the file system may be using some internal data st=
ructure to represent long sequences of null bytes rather than the literal s=
equence does not matter to the reader, in the same way that it does not mat=
ter if the file system keeps the file compressed on disk and decompresses a=
s sections are read.</div></div></div></blockquote><div><br></div><div>This=
 line of argument is very similar to scalar vs vector arithmetic: &quot;Fro=
m the point of view of a performer of arithmetic, all math is scalar. It do=
es not matter if a vector unit is (inefficiently) used to perform scalar ma=
th&quot;.</div><div><br></div><div>And this is correct, if all you ever wan=
t to do is scalar math. Same goes for a single stream of bytes. If you don&=
#39;t care about implementation reality, sure, pretend your CPU can only ev=
er do a single arithmetic operation at a time.</div><div><br></div><div>But=
 let&#39;s widen your horizons a bit. Don&#39;t write scalar math. Write ma=
th. If it&#39;s unavoidably scalar, so be it. If the compiler can spot some=
 parallelisation in what you wrote for the target architecture, <i>far bett=
er</i>=C2=A0(usually).</div><div><br></div><div>Same goes for extents. Sure=
 you can write your application assuming they don&#39;t exist. Yet any fili=
ng system designed in the past twenty years has them, same as how any recen=
t CPU has a vector math unit which inefficiently does your scalar math on r=
equest.</div><div><br></div><div>So don&#39;t write single extent code. Wri=
te extents-based code. It&#39;ll perform no worse, and always much better, =
on discontiguous extent storage. Indeed depending on the data, discontiguou=
s extents may even lend well to embarrassing parallelism.</div><div><br></d=
iv><div>A lot of people claim that single extent code is simpler. I&#39;ve =
never bought that argument. The least additional complexity is an additiona=
l for loop to iterate the valid extents. That minor extra step turns days o=
f execution time to iterate simulated zero bytes into potentially seconds t=
o iterate the data actually stored where it&#39;s stored. It&#39;s a huge w=
in. It ought to be the default, and <b>is</b>=C2=A0the default in P1031 LLF=
IO.</div><div><br></div><div>(I&#39;m still working on Eric to agree to hav=
e Ranges do the same, I think I&#39;ve nearly won that argument. For the Ra=
nges end user, it&#39;s no difference except a vast improvement in efficien=
cy in sparsely stored files)</div><div><br></div><div>Niall</div><div><br><=
/div></div>

<p></p>

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

------=_Part_1707_473355917.1545887713630--

------=_Part_1706_1327023219.1545887713630--

.

------=_Part_1716_141578535.1545888563048
Content-Type: multipart/alternative;
 boundary="----=_Part_1717_378122721.1545888563049"

------=_Part_1717_378122721.1545888563049
Content-Type: text/plain; charset="UTF-8"


>
> APIs are made to fit the user; users should not be made to fit the API.
>

Ah come on now, that is quite literally what Boost or LEWG do: we decide
the balancing line between safety and convenience in library APIs. We more
frequently say no than say yes to convenience e.g. implicit conversions,
optional<T&> and so on.


> The people who use this function don't care about memory mapping, dynamic
> memory allocations, memory copies or whatever. They want the file loaded
> into a string, which they can use just like any other string in the
> program. The specific details on what is the fastest way to accomplish this
> is an irrelevant detail to them.
>
> This is a high-level function for high-level needs.
>
> Again, that doesn't mean we shouldn't have ways to do memory mapped files
> and whatnot. But even if we have those techniques, we still want a simple
> API to load a file into a string.
>

I have zero opposition to "they want the file loaded into a string *view*".
But not string. And by string, I mean dynamically allocated "bunch of
char", which really should be "bunch of byte" nowadays.

I could accept a compromise of a string with a custom allocator which makes
it behave exactly like a string view. But I suspect that would induce
surprise in the end user as mismatching STL allocators in STL containers is
an amazing bundle of "fun and entertainment".

For the record, I have no issue with a *two* liner for loading a file into
a string. I have not seen a succinct single line API design I could live
with, yet. But that's because I very strongly feel that implicit memory
copies must always, always, always involve the programmer writing a
separate line. Memory copies always deserve a line feed.

Niall

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1c50b69b-b6be-4b7a-925a-51aa3e1dab80%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>APIs are made to fit the user; users should not be made to fit the=
 API.</div></div></blockquote><div><br></div><div>Ah come on now, that is q=
uite literally what Boost or LEWG do: we decide the balancing line between =
safety and convenience in library APIs. We more frequently say no than say =
yes to convenience e.g. implicit conversions, optional&lt;T&amp;&gt; and so=
 on.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div> The people who use this function don&#39;t care about m=
emory mapping, dynamic memory allocations, memory copies or whatever. They =
want the file loaded into a string, which they can use just like any other =
string in the program. The specific details on what is the fastest way to a=
ccomplish this is an irrelevant detail to them.</div><div><br></div><div></=
div><div>This is a high-level function for high-level needs.</div><div><br>=
</div><div>Again, that doesn&#39;t mean we shouldn&#39;t have ways to do me=
mory mapped files and whatnot. But even if we have those techniques, we sti=
ll want a simple API to load a file into a string.</div></div></blockquote>=
<div><br></div><div>I have zero opposition to &quot;they want the file load=
ed into a string <i>view</i>&quot;. But not string. And by string, I mean d=
ynamically allocated &quot;bunch of char&quot;, which really should be &quo=
t;bunch of byte&quot; nowadays.</div><div><br></div><div>I could accept a c=
ompromise of a string with a custom allocator which makes it behave exactly=
 like a string view. But I suspect that would induce surprise in the end us=
er as mismatching STL allocators in STL containers is an amazing bundle of =
&quot;fun and entertainment&quot;.</div><div><br></div><div>For the record,=
 I have no issue with a <b>two</b> liner for loading a file into a string. =
I have not seen a succinct single line API design I could live with, yet. B=
ut that&#39;s because I very strongly feel that implicit memory copies must=
 always, always, always involve the programmer writing a separate line. Mem=
ory copies always deserve a line feed.</div><div><br></div><div>Niall</div>=
<div><br></div></div>

<p></p>

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

------=_Part_1717_378122721.1545888563049--

------=_Part_1716_141578535.1545888563048--

.

--0000000000004cc4c5057dfd690f
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 27, 2018, 12:15 AM Niall Douglas <nialldouglas14@gmail.com
wrote:

> So don't write single extent code. Write extents-based code.
>>>
>>
No.  I've been programming for 40 years and I have yet to ever need to
process an entire file that had extent gaps as a single sequence.  The very
few times I dealt with such files, they were data structures on disk, with
internal offsets and sizes that I used for seeking and reading sections.

People who want to read a file into a string want exactly that.  Just
because you think they should want something else doesn't make them want
something else.

>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbCGX2TPAMh_Yniu-SG6%2BxmiZayoJeSMiBh%2BiSau_4M%2Bw%40mail.gmail.com.

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

<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Thu, Dec 27, 2018, 12:15 AM Niall Douglas &lt;<a href=3D"mailto:nialldou=
glas14@gmail.com">nialldouglas14@gmail.com</a> wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><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"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div>So don&#39;t write single extent =
code. Write extents-based code.</div></div></blockquote></div></div></block=
quote></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">No.=C2=A0 I&#39;ve been programming for 40 years and I have yet to ever n=
eed to process an entire file that had extent gaps as a single sequence.=C2=
=A0 The very few times I dealt with such files, they were data structures o=
n disk, with internal offsets and sizes that I used for seeking and reading=
 sections.</div><div dir=3D"auto"><br></div><div dir=3D"auto">People who wa=
nt to read a file into a string want exactly that.=C2=A0 Just because you t=
hink they should want something else doesn&#39;t make them want something e=
lse.</div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
</blockquote></div></div>

<p></p>

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

--0000000000004cc4c5057dfd690f--

.