<div dir="ltr">I was not intending for C++11 to be a big part of the discussion as it is a much more complicated topic, but I do appreciate the discussion.  I picked the stack + memset -> std::vector(nSize, initialValue) to do first because I thought it was a simpler issue than most and we could use it to figure out how to go about these sorts of discussions.  It's not a show stoper, but it is a real need.<div><br></div><div>At this point, I think it would be good if we could pause the C++11 discussion for a bit and back up to the original question.</div><div><br></div><div>I'd like to ask folks a couple of things:</div><div><br></div><div>- If you could stack rank (all or some) the options assuming that C++14 was available</div><div>- Is your top pick far better than the rest or just a little better?</div><div>- Are there any options that you think should not be used in GDAL?</div><div>- Are there any reasons to be for or against any particular alternative that we need to call out?</div><div><br></div><div>My belief is that for this particular proposal, we should not have the C++11/14 discussion unless the best overall solution requires a newer version of C++.  The solution I propose to be the best works in C++03 and newer.</div><div><br></div><div><br></div><div><div><div class="gmail_extra"><div class="gmail_quote">On Thu, May 5, 2016 at 2:25 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> I misinterpreted this thread because of the title.  It seems this isn't<br>
> really about code style or C++ 11.<br>
<br>
</span>I agree this thread mixes different topics, which causes some confusion. The<br>
word C++11 appearing in a doc has created some passion, whereas it is probably<br>
not the heart of the subject.<br>
<br>
Kurt has contributed to a lot of cleanup in the code base over the last<br>
months, mostly in applying stricter formatting rules, bool'ifying,<br>
const'ifying when possible, moving variable declarations close to their<br>
initialization, etc.. (Kurt, correct me if I'm wrong.), also addressing a<br>
bunch of Covertiy Scan warnings, etc.<br>
<br>
I've actually encouraged him to share his thoughts regarding cleanups with the<br>
rest of the community so that we can decide which are worth to be rules that<br>
apply to the project as a whole, and if some tooling is needed to<br>
automate/enforce them.<br>
<span class=""><br>
> It's really about Google wanting to use<br>
> heap over stack because of its particular use of the library.  There is no<br>
> need for C++ 11 for that and it would seem that doing a compile-time<br>
> policy-based array isn't too hard (proof of concept below).  Perhaps Google<br>
> could flush something like this out to its liking and replace current stack<br>
> allocations that cause it issues.<br>
<br>
</span>This use case is probably shared by other actors that use GDAL for massive<br>
data processing, and if the solution to reduce stack usage doesn't hurt more<br>
mundane use cases, we probably don't need the #ifdef complication.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div></div></div></div>