http://www.keittlab.org/
On Fri, May 6, 2016 at 1:55 PM, Kurt Schwehr <schw...@gmail.com> wrote: > 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. > > 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. > > I'd like to ask folks a couple of things: > > - If you could stack rank (all or some) the options assuming that C++14 > was available > 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). > - Is your top pick far better than the rest or just a little better? > - Are there any options that you think should not be used in GDAL? > - Are there any reasons to be for or against any particular alternative > that we need to call out? > Always prefer vanilla standard library over others. > > 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. > 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. THK > > > On Thu, May 5, 2016 at 2:25 PM, Even Rouault <even.roua...@spatialys.com> > wrote: > >> >> > I misinterpreted this thread because of the title. It seems this isn't >> > really about code style or C++ 11. >> >> I agree this thread mixes different topics, which causes some confusion. >> The >> word C++11 appearing in a doc has created some passion, whereas it is >> probably >> not the heart of the subject. >> >> Kurt has contributed to a lot of cleanup in the code base over the last >> months, mostly in applying stricter formatting rules, bool'ifying, >> const'ifying when possible, moving variable declarations close to their >> initialization, etc.. (Kurt, correct me if I'm wrong.), also addressing a >> bunch of Covertiy Scan warnings, etc. >> >> I've actually encouraged him to share his thoughts regarding cleanups >> with the >> rest of the community so that we can decide which are worth to be rules >> that >> apply to the project as a whole, and if some tooling is needed to >> automate/enforce them. >> >> > It's really about Google wanting to use >> > heap over stack because of its particular use of the library. There is >> no >> > need for C++ 11 for that and it would seem that doing a compile-time >> > policy-based array isn't too hard (proof of concept below). Perhaps >> Google >> > could flush something like this out to its liking and replace current >> stack >> > allocations that cause it issues. >> >> This use case is probably shared by other actors that use GDAL for massive >> data processing, and if the solution to reduce stack usage doesn't hurt >> more >> mundane use cases, we probably don't need the #ifdef complication. >> >> -- >> Spatialys - Geospatial professional services >> http://www.spatialys.com >> > > > > -- > -- > http://schwehr.org > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
