On 8 May 2016 at 07:01, Kurt Schwehr <schw...@gmail.com> wrote: > > Are meaning to say that my proposal is vague?
Yes, I called that on the course of the discussion, it has become less and less clear to me: what is the actual goal? - make the stack/heap usage more configurable - use new C++ features to introduce widely recommended idioms - make the code shorter, hence clearer/more readable/maintainable - make the code more C++ than C by allowing wide use of C++ standard features ... So, in order to achive the above, you are proposing switch to newer C++ version? > Please read the proposal as just looking at the possibilities. > Please try not to care about C++ language version when > trying to do a first round review of ideas. I have and as far as I can see, there are just two objectives: 1. Make GDAL stack-friendly by preferring heap for arrays. How? Use standard containers and smart pointers. 2. Introduce RAII across the whole codebase. How? Use smart pointers and other related techniques. That's all I can see from most of the content there. (The many fine-grained details are not critical to make the actual 'big' decisions, those will come into play later.) So, as I have already mentioned, great. Now, let's decide wheter we switch to C++11 to get the necessary tools or implement our own tools, e.g. as part of CPL. I believe, much of the discussion would have gained more focus if the problem was stated like that. > On Fri, May 6, 2016 at 2:47 PM, Mateusz Loskot <mate...@loskot.net> wrote: >> >> On 6 May 2016 at 21:55, Kurt Schwehr <schw...@gmail.com> wrote: >> > 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. >> >> Considering current codebase, GDAL is written in C and compiled in C++. >> The only major C++ feature used in GDAL is classes and polymorphism. > > > I agree that GDAL has a strong feel of C compiled with C++ right now. Since that is a fact, there is nothing to agree about. Please, notice, I'm not speaking here about my personal preferences, just the state of the art. > I disagree about C++ feature use. I see algorithm, iostream, map, list, > sstream, a few exceptions, std::string (mostly in the form of CPLString), > vector, localization of variables, some templates, #define to static consts, > etc. In GDAL? e.g. streams are not used or they use is marginal. >> If you ask any seasoned C programmer for opinion, I bet she will >> consider GDAL codebase as clear and readable. >> If you ask a C++ programmer, the answer might be different. >> >> IMO, I doubt any C++11/14 feature will increase the current code, >> unless it is considered to ditch many of CPL features and replace >> them with C++ standard features (string bashing operations, string >> containers, >> containers for other types, threading API, etc.). >> > > "increase the current code" <- Did you mean increase the reliability? Or > size? Or complexity? Sorry, sloppy typing. I meant code clarity, readability. >> Certainly, any new line to be written may benefit from auto, >> constexpr, using, nullptr, range loops - but for a "C with classes" >> codebase as GDAL, it would be cosmetic improvement, if any. >> > > I disagree that C++11/14 changes would be cosmetic. But this is the wrong > thread for this part of the discussion. IMHO, you are missing one important point. I'm not arguing that shifting from C with classes mode to C++11-17 is not going to increase software quality. Of course it is, if applied properly and *at all*. Have you considered current maintainers might not be willing to start using the latest and the greatest C++11-17 features? If they are not...changes will be rather cosmectic. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev