<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 2:47 PM, Mateusz Loskot <span dir="ltr"><<a href="mailto:mateusz@loskot.net" target="_blank">mateusz@loskot.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 6 May 2016 at 21:55, Kurt Schwehr <<a href="mailto:schwehr@gmail.com">schwehr@gmail.com</a>> wrote:<br>
> My belief is that for this particular proposal, we should not have the<br>
> C++11/14 discussion unless the best overall solution requires a newer<br>
> version of C++.  The solution I propose to be the best works in C++03 and<br>
> newer.<br>
<br>
Simply, the initial proposal was quite confusing.<br>
<br>
The 'title' said indicated it was "mostly focused on C++11/14 & C99/11",<br>
while the content mentioned mostly the std::vector as malloc'ed arrays<br>
replacement.<br>
<br>
Considering current codebase, GDAL is written in C and compiled in C++.<br>
The only major C++ feature used in GDAL is classes and polymorphism.<br>
<br>
I'm not sure if the facts mentioned in the proposal, namely<br>
"Want to focus on maintainability and readability of code",<br>
is meant to be a fact or a goal.<br>
If you ask any seasoned C programmer for opinion, I bet she will<br>
consider GDAL codebase as clear and readable.<br>
If you ask a C++ programmer, the answer might be different.<br>
<br>
IMO, I doubt any C++11/14 feature will increase the current code,<br>
unless it is considered to ditch many of CPL features and replace<br>
them with C++ standard features (string bashing operations, string containers,<br>
containers for other types, threading API, etc.).<br></blockquote><div><br></div><div>That's exactly my preference. For those of us who have to remember too many things, using the standard library is a godsend because it is exceptionally well documented online and used in many places.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Certainly, any new line to be written may benefit from auto,<br>
constexpr, using, nullptr, range loops - but for a "C with classes"<br>
codebase as GDAL, it would be cosmetic improvement, if any.<br></blockquote><div><br></div><div>It is true that unless you refactor along the lines of Boost, then these features are not used as effectively.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Surely, the override and final will help compiler to catch potential bugs.<br>
Also, C++11/14 compilation mode is generally stricter, so it might<br>
help to catch bugs.<br></blockquote><div><br></div><div>My experience with C++11 is that it is vastly less error prone and more readable. But of course there is a big cost to rewriting code, so I understand the conundrum.</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">
<br>
Simply, the whole proposal is becoming vague.<br>
<br>
Best regards,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer" target="_blank">http://mateusz.loskot.net</a><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></font></span></blockquote></div><br></div></div>