Even, Got it, thanks. I'm thinking of the case analogous to GDALDataset, OGRGeometry and others that have a fromHandle() method. That is occasionally helpful, when we use primarily the C APIs but there is some public C++ method not exposed in C that we want to use (i.e., "public" via gdal_priv.h in the case of dataset). But yeah a workaround there too, not needed often.
WIth GDALAlgorithmArg there is a "hidden" flag that can be accessed with GDALAlgorithmArg::IsHidden(). It seems to to mean the arg is hidden in both CLI and non-CLI "application" contexts, i.e., should not be given as a user option in either context? In the C API there is GDALAlgorithmArgIsHiddenForCLI() and GDALAlgorithmArgIsOnlyForCLI(), but with those I can't tell for sure if the arg should be hidden either way (e.g., "help-doc" but potentially others it looks like). Chris On Thu, Aug 7, 2025 at 2:56 AM Even Rouault <even.roua...@spatialys.com> wrote: > > Chris, > > why would you need it to be exposed ? If it is to workaround missing C > API entry points, we should add them > > Regarding struct GDALAlgorithmHS being exposed in gdalalgorithm.h, this > is because another GDAL .cpp file needed it, but I think I should create > instead a gdalalgorithm_priv.h header to move those struct definitions. > Please don't rely on the internals of struct GDALAlgorithmHS > > Even > > Le 07/08/2025 à 06:44, Chris Toney a écrit : > > Hi Even, > >> If you need this in 3.11, you can define the following implementation > >> detail in your code > >> > >> struct GDALAlgorithmArgHS > > Could GDALAlgorithmArgHS be defined in gdalalgorithm.h (as struct > > GDALAlgorithmHS is)? > > > > Chris > > > > > > On Mon, Aug 4, 2025 at 2:42 AM Even Rouault <even.roua...@spatialys.com> > > wrote: > >> Hi Chris, > >> > >> This was indeed missing in the C API. Queued for 3.12 in > >> https://github.com/OSGeo/gdal/pull/12853 > >> > >> If you need this in 3.11, you can define the following implementation > >> detail in your code > >> > >> struct GDALAlgorithmArgHS > >> { > >> GDALAlgorithmArg *ptr = nullptr; > >> > >> explicit GDALAlgorithmArgHS(GDALAlgorithmArg *arg) : ptr(arg) > >> { > >> } > >> }; > >> > >> but better conditionalize it to 3.11 only, so that to avoid issues in > >> later version if we would change the definition of struct > >> GDALAlgorithmArgHS > >> > >> and then do things like > >> > >> GDALAlgorithmArgH hArg; > >> > >> hArg->ptr->GetDefault<std::string>(); > >> > >> Even > >> > >> > >> Le 04/08/2025 à 03:46, Chris Toney via gdal-dev a écrit : > >>> Hi, > >>> In the C API there is GDALAlgorithmArgHasDefaultValue(), but no > >>> interface to the GetDefault() class method to access the value itself > >>> when there is one (nor in the Python bindings, AFAICS). > >>> > >>> I don't believe there is a fromHandle() method on GDALAlgorithmArg to > >>> get to the C++ object. > >>> > >>> Is there possibly a workaround for that when working through the C API? > >>> > >>> Chris > >>> _______________________________________________ > >>> gdal-dev mailing list > >>> gdal-dev@lists.osgeo.org > >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev > >> -- > >> http://www.spatialys.com > >> My software is free, but my time generally not. > >> > -- > http://www.spatialys.com > My software is free, but my time generally not. > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
