关于可移植的浮点数操作

starwing83

C标准在这一块实在是太混乱了……除了预定义了IEEE_xxx预处理符以外就没干过什么事儿。float.h里面的内容太过繁杂了……问问，有没有人知道有什么标准的库可以操作浮点数的？具体是这样：

1. 取得浮点数的所有bits，按照规则填入某个确定的结构体（fpbits）
2. 能将浮点数输出成hexaformat的字符串（C99 printf的%a实现）
3. 能按照规则将浮点数输出成字符串（C99 printf的f，d，e，E，g，G等等实现）

关键是体积小，移植性好，有没有人有点主意的？现在在看gdtoa这个库，体积稍微有点大了（编译出来的.a有185k……），另外代码实在很乱（这个倒不能怪他，毕竟兼顾了几乎所有的硬件平台了），不知道有没有更好的……

OwnWaterloo

>> 2. 能将浮点数输出成hexaformat的字符串（C99 printf的%a实现）

1. 
   
2. double x = ...;
   
3. unsigend char bytes[sizeof x];
   
4. memcpy(bytes, &x, sizeof x);
   

复制代码

然后按整数来？


>> 1. 取得浮点数的所有bits，按照规则填入某个确定的结构体（fpbits）

取bits和上面一样吧。。。
"所有bits"的意思其实是将所有bits分类并取出？ 解析bit pattern？
这C标准肯定不会规定的。。。 连整数都暧昧不明。。。  就不要指望浮点了。。。


>> 3. 能按照规则将浮点数输出成字符串（C99 printf的f，d，e，E，g，G等等实现）

同上。。。 C就是这么拽。。。


>> 这个倒不能怪他，毕竟兼顾了几乎所有的硬件平台了

这样呢？ 就先只负责IEEE754。
对其他的找个靠谱的fallback。。。 比如你提到的那个gdtoa，又或者libc。。。
等真正遇到非IEEE754的时候再说。。。

这么多古怪的机器哪有精力研究完。。。
说不定gdtoa支持的那些"所有"硬件平台当中许多都已经不存在了呢。。。


BTW：如果找到满意的了麻烦通知一声。。。

starwing83

回复 2# OwnWaterloo


    剩下两个同意，第一个你理解错了，hexaformat不是说的把浮点当作整数然后得到16进制表示，而是一种特殊的浮点数表示格式，比如说1.23456的hexaformat就是0x1.3c0c20p+0，理论上可以根据hexaformat完全还原一个浮点数的。所以这货其实依赖1)的实现（得把浮点数按照结构划分开），不然就没治。

其实我也不想这么麻烦，遇到问题转发给sprintf也就算了。问题是1)该死的微软的printf根本不支持%a的格式（C99规范） 2)微软没有snprintf。这样基本上浮点这一块就没辙了。所以我得想办法自己弄一个出来。

starwing83

回复 2# OwnWaterloo


    还有，IEEE754也分大小端，处理起来也未必轻松………………

OwnWaterloo

回复 3# starwing83

我的错。。。 也就是3个都需要理解浮点格式了。。。

微软好像有snprintf，只是不叫这个名字。。。

也就是说。。。 在windows上一个靠谱的fallback都找不到？
gdtoa呢？ 非windows上的libc呢？（mingw好像也是直接用的ms的runtime...）
还有windows只支持几个硬件平台的吧。。。 它们是不是都是ieee754的。。。？

OwnWaterloo

回复 4# starwing83

大小端比浮点格式容易吧？
大小端也是所有byte换顺序吧？ 不是几个part当中的bits换顺序吧。。。 这就烦了。。。

folklore

@starwing83

微软没有snprintf

http://msdn.microsoft.com/ja-jp/library/vstudio/2ts7cx93.aspx

1. 取得浮点数的所有bits，按照规则填入某个确定的结构体（fpbits）

除了自已解析IEEE，没想到什么好办法，不然写个自定义的float的类。如果要支持3D运算，因为和硬件相关，基本就更法子了

2. 能将浮点数输出成hexaformat的字符串（C99 printf的%a实现）
3. 能按照规则将浮点数输出成字符串（C99 printf的f，d，e，E，g，G等等实现

简单点的，就写个myprintf,在里面除了解析%a外，都二转给vsprintf吧。。。

starwing83

回复 5# OwnWaterloo


    似乎有个sprintf_s，但是据说语义不太一样……

反正如果是IEEE_x的话，会定义这个预处理符的，所以如果真要解析也不是什么很困难的事情……

MinGW就猥琐了……从glibc里面提了一个snprintf，用的就是这个，其他的才转发给msvcrt，也就是说，如果限定MinGW倒也没多大问题，但是最终编译的大小会增加40K左右的样子…………然后MSVC就完蛋了。

如果下定决心分析IEEE754也还好，可是这个标准的执行也语焉不详。比如说long double吧，有些平台是80，有些平台是64，你咋搞……

总的来说就是困难啊………………

Lua的源代码里面很简单的用LUA_USE_AFORMAT判定是否支持%a……典型的鸵鸟策略……不过也很成功就是了……然后Lua完全放弃了snprintf，而采取预先计算长度，然后用确定的format让sprintf搞事……也不是不可以，但是计算长度的代码很那个啥……

starwing83

回复 7# folklore


    应该是非常后期才加，msvcrt里面就别想了，如果用了可能导致dll依赖msvcrtxxx.dll，这个很麻烦的。

%a的问题我记错了，好像微软是支持的，但是有bug（？）反正Lua邮件列表专门讨论过这些问题。

我打算放弃了，整数部分我自己搞，浮点转发给sprintf好了……反正这几个精度都是确定的，那么长度就很好确定了……