<div dir="ltr"><div>I was trying to give people an overall sense of my goals for GDAL.</div><div><br></div><div>I'm sorry I added the context to the proposal that got the discussion off the track I intended. I am more interested in mechanics of the discussion before hitting huge topics. I love the discussion, but I feel like I totally failed at trying to test strategy for the GDAL community to have discussions and get some basics added to the style guide with some why attached. I think we have lots to discuss before tooling and newer versions of C++. There are lots of implicit style things in GDAL that I have been trying to bend my coding to, but I find clashing styles in the same file all the time, so it is hard to get what I do to match.<br></div><div><br></div>Just for this proposal... I do let myself get dragged a bit into the C++ version discussion a bit below to try to show that it is off topic of >>>getting large objects off the stack<<<.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 5:59 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On 8 May 2016 at 07:01, Kurt Schwehr <<a href="mailto:schwehr@gmail.com">schwehr@gmail.com</a>> wrote:<br>
><br>
> Are meaning to say that my proposal is vague?<br>
<br>
</span>Yes, I called that on the course of the discussion, it has become less and less<br>
clear to me: what is the actual goal?<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- make the stack/heap usage more configurable</blockquote><div><br></div><div>No. Not configurable. I propose to get large objects off the stack unless a particular case severely impacts performance.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- use new C++ features to introduce widely recommended idioms<br></blockquote><div><br></div><div>No. I do not propose using any C++ features new to GDAL. This is just the old vector size with initializer constructor.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- make the code shorter, hence clearer/more readable/maintainable<br></blockquote><div><br></div><div>No. Shorter wasn't a goal for this one. It's sorter because my proposed solution combines the definition and the initialization so as to not have an uninitialized variable after the definition until the memset.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- make the code more C++ than C by allowing wide use of C++ standard features<br></blockquote><div><br></div><div>No.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
...<br>
So, in order to achive the above, you are proposing switch to newer C++ version?<br></blockquote><div><br></div><div>No. I was trying to be complete in going through all the options available inside and out of GDAL. Only if the community really wanted a feature from C++ >= 11 would I consider the language version a part of this proposal.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> Please read the proposal as just looking at the possibilities.<br>
> Please try not to care about C++ language version when<br>
> trying to do a first round review of ideas.<br>
<br>
</span>I have and as far as I can see, there are just two objectives:<br>
1. Make GDAL stack-friendly by preferring heap for arrays.<br>
How? Use standard containers and smart pointers.<br></blockquote><div><br></div><div>That is 3 statements:</div><div><br></div><div>a) Make GDAL stack-friendly by preferring heap for arrays.</div><div><br></div><div>Yes.</div><div><br></div><div>b) How? Use standard containers</div><div><br></div><div>Yes. I propose this</div><div><br></div><div>c) and smart pointers</div><div><br></div><div>No. In this case, a smart pointer looks to be less attractive (to me).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
2. Introduce RAII across the whole codebase.<br>
How? Use smart pointers and other related techniques.<br></blockquote><div><br></div><div>No! Out of scope of this proposal. (For another proposal, then yes).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
That's all I can see from most of the content there.<br>
(The many fine-grained details are not critical to make the actual<br>
'big' decisions, those will come into play later.)<br>
<br>
So, as I have already mentioned, great.<br>
Now, let's decide wheter we switch to C++11 to get the necessary tools or<br>
implement our own tools, e.g. as part of CPL.<br></blockquote><div><br></div><div>No. Please do not do that with my proposal. That is way way too far out of scope of what I intended for *this* proposal. Can we start with just this simple proposal?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I believe, much of the discussion would have gained more focus if the problem<br>
was stated like that.<br></blockquote><div><br></div><div>Yeah, I missed the boat on focus. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> On Fri, May 6, 2016 at 2:47 PM, Mateusz Loskot <<a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a>> wrote:<br>
>><br>
>> 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<br>
>> > and newer.<br>
>><br>
</span><span class="">>> 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>
><br>
> I agree that GDAL has a strong feel of C compiled with C++ right now.<br>
<br>
</span>Since that is a fact, there is nothing to agree about.<br>
Please, notice, I'm not speaking here about my personal preferences,<br>
just the state of the art.<br>
<span class=""><br>
> I disagree about C++ feature use. I see algorithm, iostream, map, list,<br>
> sstream, a few exceptions, std::string (mostly in the form of CPLString),<br>
> vector, localization of variables, some templates, #define to static consts,<br>
> etc.<br>
<br>
</span>In GDAL? e.g. streams are not used or they use is marginal.<br></blockquote><div><br></div>
<p class=""><span class="">find . -name \*cpp | xargs grep include | grep stream | wc -l</span></p>
<div>53</div><div><br></div><div>find . -name \*cpp | xargs grep -h include | grep stream | sort -u</div><div>#include <fstream></div><div>#include <iostream></div><div>#include "mrsidstream.h"</div><div>//#include <sstream></div><div>#include <sstream></div><div>#include <strstream> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
<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<br>
>> containers,<br>
>> containers for other types, threading API, etc.).<br>
>><br>
><br>
> "increase the current code" <- Did you mean increase the reliability? Or<br>
> size? Or complexity?<br>
<br>
</span>Sorry, sloppy typing. I meant code clarity, readability.<br>
<span class=""><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>
>><br>
><br>
> I disagree that C++11/14 changes would be cosmetic. But this is the wrong<br>
> thread for this part of the discussion.<br>
<br>
</span>IMHO, you are missing one important point.<br>
I'm not arguing that shifting from C with classes mode to C++11-17<br>
is not going to increase software quality. Of course it is, if applied<br>
properly and *at all*.<br>
<br>
Have you considered current maintainers might not be willing to start using<br>
the latest and the greatest C++11-17 features?<br>
If they are not...changes will be rather cosmectic.<br></blockquote><div><br></div><div>Yes, I understand this. If you look at this proposal, you will find that I was not proposing >= C++11. I am working on a proposal for newer versions. I am thinking gradually. There are non-cosmetic things that are not very different but just work way better in the new standards. And if we go through a proposal process, you can have/should demand clean examples. And I think we should have a vote on these features. If maintainers are not ready for a feature, then vote against it! Try to think of baby steps. If we say yes to C++11 being required, I think my first proposal would be to switch NULL to nullptr (which is typed). My experience is that it does catch a number of strange edge case issues. They are rare, but I have hit them. While GDAL isn't huge, GDAL is big enough that NULL might be be hiding these issues or it might happen in future commits. I don't think changing NULL to nullptr shouldn't be too scary to C coders.</div><div><br></div><div>Even just switching the C++ version to C++11 would improve checking w.r.t. the std lib, reduce the testing load on travis-ci, let us drop a couple macros, and slightly simplify the build system.</div><div><br></div><div>But, all that is out of scope of my first proposal.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
Best regards,<br>
--<br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer" target="_blank">http://mateusz.loskot.net</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>