[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