在C++ 11中,我们提供了固定宽度的整数类型,例如std::int32_t和std::int64_t,它们是可选的,因此不是编写跨平台代码的最佳选择.然而,我们也得到了各类非可选变型:例如"快"的变体,如std::int_fast32_t和std::int_fast64_t,以及"最小尺寸"变体,例如std::int_least32_t,它都至少指定数目的大小位.
我正在处理的代码是基于C++ 11的跨平台库的一部分,它支持在最流行的Unix/Windows/Mac编译器上进行编译.现在出现的一个问题是,如果用C++ 11固定宽度整数类型替换代码中的现有整数类型是否有优势.
使用类似变量的缺点std::int16_t和std::int32_t是缺乏保证它们是可用的,因为只提供他们如果实现直接支持的类型(根据http://en.cppreference.com/w/cpp/types/integer).
但是,因为int至少16位且16位对于代码中使用的整数足够大,所以使用std::int_fast16_tover int呢？它提供了一个好处,以取代所有int类型的std::int_fast16_t,所有unsigned int通过的std::uint_fast16_t那样,或者这是不必要的？
Anologously,如果知道所有支持的平台和编译器配备了int至少32位的大小,是否有意义通过替换他们std::int_fast32_t和std::uint_fast32_t分别？
Yak*_*ont 23
int在当前的计算机和编译器上可以是16位,32位甚至64位.在未来,它可能更大(例如,128位).
如果你的代码没问题,那就去吧.
如果您的代码仅经过测试并使用32位整数,那么请考虑使用int32_t.然后代码将在编译时失败,而不是在没有32位整数的系统上运行时运行时(这在今天极为罕见).
int_fast32_t是你需要至少32位,但你关心性能.在32位整数作为64位整数加载的硬件上,在繁琐的过程中位移回到32位整数,int_fast_32_t可以是64位整数.这样做的代价是,在不起眼的平台上,您的代码行为完全不同.
如果您没有在这样的平台上进行测试,我会建议不要这样做.
在构建时间中断事情通常比在运行时休息更好.如果您的代码实际上是在需要这些功能的某个不起眼的处理器上运行,那么请修复它.适用"你可能不需要它"的规则.
保守,在未经过测试的硬件上生成早期错误,并且当您需要移植到所述硬件时,需要进行可靠的工作和测试.
简而言之:
int_fast##_t当且仅当您在int大小变化的平台上测试了代码(并将继续测试它)时才使用,并且您已经证明性能改进值得将来维护.
使用int##_t常见##大小意味着您的代码将无法在尚未测试它的平台上进行编译.这很好; 未经测试的代码不可靠,不可靠的代码通常比无用的更差.
在不使用int32_t和使用的情况下int,您的代码有时会有int32个,有时是64个(理论上更多),有时int是16个.如果您愿意在每个这样的情况下测试和支持每个这样的情况int,去吧.
请注意,数组int_fast##_t可能存在缓存问题:它们可能不合理地大.例如,int_fast16_t可以是64位.一个数千或数百万的阵列可以单独快速使用,但是由它们的批量导致的缓存未命中可能使它们整体变慢; 并且事情变得缓慢存储的风险也在增加.
int_least##_t 在这些情况下可以更快.
除了网络传输和文件存储数据之外,网络/文件数据通常必须遵循对编译器/硬件更改稳定的格式这一明显问题同样适用于网络传输和文件存储数据.然而,这是一个不同的问题.
但是,在使用固定宽度整数类型时,必须特别注意int,long等仍具有与之前相同的宽度.整数提升仍然基于int的大小发生,这取决于您使用的编译器.代码中的整数将是int类型,具有关联的宽度.如果使用其他编译器编译代码,这可能会导致不必要的行为.有关更多详细信息,请访问:https://stackoverflow.com/a/13424208/3144964
| 归档时间： |
|
| 查看次数： |
2791 次 |
| 最近记录： |