<div dir="auto"><div dir="ltr"><div><div>Tony:<br><br></div>     Good catch, thank you! I updated that immediately and started a changelog for revision 1.<br><br></div><span style="font-family:sans-serif">Máté:</span><br><br><div>     I am not sure I agree with the direction you&#39;re going in. Turning all of  &lt;iostream&gt; constexpr is far, far overkill for the problem at hand, and requires tens of high-priority targets to be standardized beforehand. I also do *not* imagine Committee consensus on making it happen, as many (including myself) view iostreams as something to be occasionally fixed and perhaps ultimately replaced in the future.<br><br></div><div>     On the subject of &quot;making a type that has usage and vocabulary similar to what we are used to&quot;: operator&lt;&lt; syntax for this is extremely overkill, and opens up many very questionable use cases. While one can imagine that they could do some sort of compile-time I/O and create files based on complex constexpr calculations, it takes a very well-defined API and then throws it into chaos.<br><br></div><div>     Where does a &quot;constexpr std::ifstream(&quot;file.txt&quot;);&quot; get &quot;file.txt&quot;? In C and C++, `fopen()`s handling of the Null Terminated Byte String is implementation-defined: but, that implementation-defined behavior has been incredibly well-defined for decades. If you turn &lt;iostream&gt; constexpr, `file.txt` can have two meanings based on whether the function is invoked at compile-time or at execution-time. (One pulls from an implementation defined &quot;constexpr&quot; path, the other pulls from the defacto current working directory).<br><br></div><div>     What makes this scary is that something can be evaluated at compile-time without you adding the `constexpr` keyword to the variable it is saved into. It would mean that every usage of `std::ofstream` where you potentially pass in constant expressions might end up being a candidate for this functionality. You would be lucky if &quot;file.txt&quot; did not live where the compiler could find it, because then you would have an error. If not, you just have bugs, lurking and waiting to blow your program up.<br><br></div><div>     I explicitly chose a different API because we cannot afford to make room for this, or to conflate meaning. We need a clear, well-defined, minimal way of gettings bytes from a file into our programs at compile-time. We will let the user constexpr or parse anything else they desire to make it worth their while.<br></div><div><br></div><div dir="auto">It is very important we reduce potential impact, and with the committee not behind allowing you to explicitly opt-in to knowing about when you are in a constexpr context (constexpr() operator was shut down, and for well-thought-out reasons), things with well-defined, different names are necessary.</div></div><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Sat, May 12, 2018 at 4:32 AM, Nagy-Egri Máté Ferenc <span dir="ltr">&lt;<a href="mailto:nagy-egri.mate@wigner.mta.hu" rel="noreferrer noreferrer" target="_blank">nagy-egri.mate@wigner.mta.hu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="#954F72" lang="HU"><div class="m_7592535047224820111m_166963971612632008m_-8760590599253785368WordSection1"><p class="MsoNormal">Indeed, I’ve thought of that after I sent the mail. Your embed is analogous to std::fread(). I even tried to find the place where MSVCs STL invokes std::fread() under the hood, but I could not find the place. There is a std::basic_streambuf::xsgetn(){ …; _Traits::copy(); } function over the input tellg() pointer in std::streambuf it won’t let me step into that should be doing the magic. I’m not sure if std::embed() fundamentally differs from std::fread(). If it does (and should), by all means, we do need it.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I deal with a bunch of GPU APIs, graphics and compute alike, and loading shaders, kernels in source or binary is a daily task. Some APIs take of this under the hood (C++AMP), some allow implementations to outsource it to the build system (ComputeCpp, a SYCL implementation in their CMake and MSBuild integration), others provide mechanisms to do it both run-time and compile-time (OpenCL clCreateProgramWithSource vs. clCreateProgramWithBinary)… the spectrum is wide and I do want something like this. (Although my primary motivation is configuring TMP and the ABI of my code through a proper JSON file that has a schema and can be validated. Also, having libraries like C++/WinRT and XAML be implementable inside the C++ compiler alone and have IntelliSense light up without any external tooling; although the latter required static reflection.) I only aked „Could you import your data easily in a run-time manner?” was only to prove the point that everyone is already familiar with one workflow and syntax from C++ 101, and there’s nothing in that method that inherently would outrule it from working in a constexpr context.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Don’t get me wrong, I WANT this to happen. I just want to propose in trying to get the right syntax, something that automagically lights up other parts of the language, or at least allows them to. I’de like to avoid duplicates like std::span and std::string_view. The fact that actually std::string_view is not just an alias or specialisation of std::array_view&lt;char&gt; is a failure in abstraction. A view of a const char* and a view of const float* share a great deal of common functionality. Strings do have some useful extra, but the commonality should reflect in the type system. We are heading towards totally different names with totally different semantics.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Let’s not do the same with std::embed, that’s all I vote for. If it’s not going to share any commonality with current file IO, I’ll just put it among the rest of things I don’t agree with and use it nonetheless.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Cheers,</p><p class="MsoNormal">Máté</p><p class="MsoNormal"><u></u> <u></u></p><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal" style="border:none;padding:0cm"><b>Feladó: </b><a href="mailto:corentin.jabot@gmail.com" rel="noreferrer noreferrer" target="_blank">Corentin</a><br><b>Elküldve: </b>2018. május 12., szombat 10:26<br><b>Címzett: </b><a href="mailto:tooling@open-std.org" rel="noreferrer noreferrer" target="_blank">WG21 Tooling Study Group SG15</a><br><b>Tárgy: </b>Re: [Tooling] [ std::embed ] Getting Data into C++ at Build Time</p></div><div><div class="m_7592535047224820111m_166963971612632008h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">They are orthogonal idea.</p></div><div><p class="MsoNormal">This paper puts a chunk of data in the program data section, then you can, at run time, use iostream on it to read the data, if you want.</p></div><div><p class="MsoNormal">Embedding resources in an application is very useful and there has been a number of tool to do that ( rcc, rc, xrc, etc etc). </p></div><div><p class="MsoNormal">It&#39;s not always desirable to open the file at runtime ( think of applications shipped as a single binary, like a windows installer) - or even feasible (on embedded targets there may not be a file system at all)</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Le sam. 12 mai 2018 à 09:59, Nagy-Egri Máté Ferenc &lt;<a href="mailto:nagy-egri.mate@wigner.mta.hu" rel="noreferrer noreferrer" target="_blank">nagy-egri.mate@wigner.mta.hu</a>&gt; a écrit :</p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><div><div><p class="MsoNormal">Hi!</p><p class="MsoNormal"> </p><p class="MsoNormal">First of all, thank you for the mental sider to my Saturday morning coffee. <span style="font-family:&quot;Segoe UI Emoji&quot;,sans-serif">😊</span> I do enjoy reading technical stuff to get my brain going.</p><p class="MsoNormal"> </p><p class="MsoNormal">However, I would consider taking a totally alternate route for a reason you also mention along the lines of std::span, namely to avoid „type spam”. My rhetorical question would be:</p><p class="MsoNormal"> </p><p class="MsoNormal">Could you import your data easily in a run-time manner? (Of course you could.)</p><p class="MsoNormal"> </p><p class="MsoNormal">Why introduce an entirely new way to process input, when all you intend is to be able to read files at compile time? We already have a versatile way to do that at run-time through iostreams, std::ifstream to be precise. I would much sooner vote std::ifstream and related types to gain constexpr support for many reasons:</p><p class="MsoNormal"> </p><ol start="1" type="1"><li class="MsoNormal">Easier to teach. Everyone starts with std::cout &lt;&lt; „Hello, World!” &lt;&lt; std::endl; and related operations. There’s really no reason why custom type IO operators (std::istream&amp; operator&gt;&gt;(std::istream&amp; is, MyType&amp; rhs) {…}) should not translate into this brave new world. The only thing needed is std::ifstream to work in a constexpr context.</li><li class="MsoNormal">You mention the troubles of how to specify file-system paths portably, which you say could be specified via embed_options. Don’t we have a way to deal with those? Oh yeah, std::filesystem, and it just happens to be that std::ifstream has matching CTORs.</li></ol><p class="MsoNormal"> </p><p class="MsoNormal">AFAIK constexpr std::allocator is already in the works, which is needed for std::basic_streambuf to work in a constexpr context. I do understand that iostreams and formatting my possibly throw, which renders it unable to be used in constexpr contexts. However, avoiding „type spam” and multiple ways to get the same job done is enough incentive to consider making exceptions cx-friendly. (When I first heard that exceptions cannot be used in cx contexts, I was puzzled… Why not emit a #error or any compiler error on unhandled constexpr exceptions? It really is an error in the compilation process.) Alternatively, we could introduce a std::basic_cxios that does not have an exceptions() member and can only report errors through error_codes.</p><p class="MsoNormal"> </p><p class="MsoNormal">I do agree that this feature would greatly simplify tooling around the language, but I think the proposals current direction is harmful. I think it’s bloating the language (STL) in ways that are not necessary. Everyone has muscle memory in how to deal with iostreams (may that be good or bad) and we should leverage as much of that as possible for simplifying things in our heads. Having constexpr std::ofstream is a totally different pothole that can wreck havoc (translation-unit crosstalk via constexpr file output Will create dependencies of source files possibly on an intra build target level), so I’m not advocating for that, even though it might have value and C++ programmers are free to shoot themselves in the foot if they see fit. Even now there are gazillions of ways to do that. If someone believes there’s enough value down that road, they should propose.</p><p class="MsoNormal"> </p><p class="MsoNormal">What are your thoughts? I don’t think I’m „bikeshedding” here, so I’m curious to what you think. Is this madness?</p><p class="MsoNormal"> </p><p class="MsoNormal">Cheers,</p><p class="MsoNormal">Máté</p><p class="MsoNormal"> </p><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b>Feladó: </b><a href="mailto:phdofthehouse@gmail.com" rel="noreferrer noreferrer" target="_blank">ThePhD</a><br><b>Elküldve: </b>2018. május 12., szombat 1:47<br><b>Címzett: </b><a href="mailto:tooling@open-std.org" rel="noreferrer noreferrer" target="_blank">tooling@open-std.org</a><br><b>Tárgy: </b>[Tooling] [ std::embed ] Getting Data into C++ at Build Time</p></div></div></div><div><div><p class="MsoNormal"> </p><div><div><div><div><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">Dear SG15,</p></div><p class="MsoNormal" style="margin-bottom:12.0pt">     Titus Winters at C++Now invited people to join the SG15 mailing list (which I didn&#39;t actually know existed!) and share their ideas. I wrote a paper about getting resource data from files into C++ in a cross-platform, compile-time way, under the name &quot;std::embed&quot; -- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r0.html" rel="noreferrer noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r0.html</a>.</p></div><p class="MsoNormal" style="margin-bottom:12.0pt">     I expect the paper to be changed quite a bit as I go to my first C++ Meeting in Rapperswil, but before I do I would like to submit the paper here. It seems like something that would be of benefit to this Study Group, as it can replace many build steps currently used today to handle the same sort of issue.</p></div></div></div></div><p class="MsoNormal">     If anyone could give me feedback about the paper, what it might meant to them, or if it even is something that truly concerns Tooling, I would greatly appreciate it!</p><p class="MsoNormal"> </p></div></div></blockquote></div><p class="MsoNormal" style="margin-left:4.8pt">_______________________________________________<br>Tooling mailing list<br><a href="mailto:Tooling@isocpp.open-std.org" rel="noreferrer noreferrer" target="_blank">Tooling@isocpp.open-std.org</a><br><a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a></p><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div><br>_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" rel="noreferrer noreferrer" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer noreferrer noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
<br></blockquote></div><br></div>
</div>