Even Rouault via gdal-dev <[email protected]> writes: > 1) updating our requirements to build GDAL to C++20 ?
This basically says that gcc 10 is not good enough, and 11 should be ok and 12 is actually ok. That seems aggressive to me, unless there's a compelling need. > 2) and making use of it in our exported C++ headers ? (thus requiring > C++ consumers of our API to also be C++20) What bad thing would happen if we don't do that? Aggressive standards can be hard to deal with, and I think it is better to be conservative especially in the exported API, absent a compelling argument. > Our current situation is C++17 required to build GDAL, and our C++ > exported headers are C++11 compatible (except some newer ones like > gdalalgorithm_cpp.h, and some bits in ) > > We already have 2 (optional) dependencies requiring C++20: Poppler and > PDFium. The next version of libarrow/libparquet will also require > C++20. Note that C++20 is currenly only enabled in GDAL in the drivers > whose dependencies require it. What problems happen if we don't bump the requirement? As I understand your description, C++20 is required if a driver that requires it is enabled, and not otherwise. That doesn't seem like a problem. _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
