[gdal-dev] argument default value in the C API to GDALAlgorithmArg

[Even Rouault]

Chris,

in the 3.11 branch "help-doc" is the only argument that calls 
SetHidden(), so you could hard code that for now, or use the workaround 
of defining the struct GDALAlgorithmArgHS

For 3.12, I've exposed GDALAlgorithmArgIsHidden() in 
https://github.com/OSGeo/gdal/pull/12890, and rationalized the naming in 
renaming IsOnlyForCLI() as IsHiddenForAPI(), so that IsHidden() == 
IsHiddenForCLI() && IsHiddenForAPI()

Even

Le 07/08/2025 à 16:22, Chris Toney a écrit :
> 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.rouault at 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.rouault at 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 at 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.
>>
-- 
http://www.spatialys.com
My software is free, but my time generally not.