[gdal-dev] Call for discussion on RFC 100: Adding Float16 support to GDAL

Even Rouault even.rouault at spatialys.com
Thu Nov 7 10:45:22 PST 2024


>
> 1) For folks compiling with C++23*, can they use std::float16_t 
> <https://en.cppreference.com/w/cpp/types/floating-point>? Sadly, 
> that's not me yet as my environment is C++20.
Letting Erik to comment on this (and also underlying that I'm very 
satisfied with the quality of the big amount work he has put on this. 
Ading a new base data type to GDAL is not for faint hearted) . Although 
I presume that it should just be a matter of typedef'ing std::float16_t 
as GFloat16, or making GFloat16 a thin wrapper of std::float16_t.
>
> 2) For when C++23 is the minimum language version for GDAL, what is 
> the plan?

Clearly not for tomorrow, seeing that a vast majority of items are red 
for MSVC. Assuming they don't drag their feet too much, I'd say 5+ years 
probably. But I'm quite puzzled to see in front of the "Requirements for 
optional extended floating-point types 
<https://en.cppreference.com/w/cpp/types/floating-point>" item, which 
covers std::float16_t that MSVC mentions "N/A" ... Does that mean they 
don't plan at all to implement that part ? Found an inconclusive post at 
https://developercommunity.visualstudio.com/t/Implement-the-C23-Extended-Precision-P/10374212


-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241107/6237c382/attachment.htm>


More information about the gdal-dev mailing list