Add RFC 109 text: Split of gdal_priv.h and addition of public C++ headers #13071
Conversation
rouault
force-pushed
the
rfc109_gdal_cpp_api
branch
3 times, most recently
from
6a66669 to
144651e
Compare
rouault
force-pushed
the
rfc109_gdal_cpp_api
branch
from
144651e to
473fa85
Compare
| - Do we need :file:`gdal_cpp.h` at all, or just keep with :file:`gdal_priv.h` ? | ||
| One advantage of :file:`gdal_priv.h` is that the name does not suggest any stability. | ||
|
|
||
| - Does the content of :file:`gdal_cpp.h` must target only the GDAL "classic 2D" and |
There was a problem hiding this comment.
I think it makes sense to either bring in the vector API or have gdal_raster.h and gdal_vector.h.
There was a problem hiding this comment.
I understand that gdal.h is the C API, while this gdal_priv.h is the C++ API, right?. I would make it obvious with the _cpp suggestion.
Raster and Vector are big enough each to join them. At most I would do something like gdal_raster_cpp.h, leaving it open to have a gdal_vector_cpp.h in the future. (Is there anything common to raster and vector in gdal_priv.h currently)
There was a problem hiding this comment.
Is there anything common to raster and vector in
gdal_priv.hcurrently)
Yes C++ classes like GDALMajorObject, GDALDataset, GDALDriver
| while still acknowledging that what it exposes might be subject to changes: | ||
| generally at least ABI changes at each feature release; sometimes API incompatible | ||
| changes occur. | ||
|
|
There was a problem hiding this comment.
A relatively minor issue, but for GDAL developers the current situation causes changes to any class definition to trigger a full library build. Splitting the headers should improve this.
| - its current inclusion of non-strictly needed GDAL headers, such as CPL ones | ||
| (:file:`cpl_vsi.h`, :file:`cpl_minixm.h`, etc.), GDAL ones (:file:`gdal_frmts.h`, | ||
| :file:`gdalsubdatasetinfo.h`) and OGR ones (:file:`ogr_feature.h`) are kept | ||
| by default. Users may define ``GDAL_PRIV_SKIP_OTHER_GDAL_HEADERS`` or ``GDAL_4_0_COMPAT`` |
There was a problem hiding this comment.
It's not clear to me in what situation these defines would be necessary. A user can either stick with gdal_priv.h which preserves current behavior, or migrate to more narrowly including what they need.
There was a problem hiding this comment.
I'm thinking to developers that want to address older GDAL releases as well, while being future proof. By defining one of those includes, they can check that they don't depend on those includes that might go away in the future
|
RFC adjusted to rename gdal_cpp.h into gdal_raster_cpp.h, and add also gdal_multidim_cpp.h and gdal_vector_cpp.h |
rouault
changed the title
==> Rendered view