<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><a href="http://www.keittlab.org/" target="_blank">http://www.keittlab.org/</a></div></div></div>
<br><div class="gmail_quote">On Fri, May 6, 2016 at 1:55 PM, Kurt Schwehr <span dir="ltr"><<a href="mailto:schwehr@gmail.com" target="_blank">schwehr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>What are the options and for what purpose? (I have not followed the thread in detail.) I'd like to see pointer types banished or if necessary wrapped with std::auto_ptr (or whichever variant makes sense).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>Always prefer vanilla standard library over others.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>I have longed for GDAL to be a modern C++ library that follows the STL, so any move in that direction would be terrific in my opinion. It would be nice to have the latest and greatest C++ bits, but I would be very happy with C++03. I strongly suggest maximizing use of the STL to avoid reinventing the wheel. If you need custom allocation, use a custom allocator with an STL data structure. I would also recommend judicious use of Boost where appropriate.</div><div><br></div><div>THK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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><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><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.<span class="HOEnZb"><font color="#888888"><br>
<div><div><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></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</font></span></div></div></div></div>
<br>_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br></blockquote></div><br></div></div>