【问题标题】:Suffix for a intmax_t literalintmax_t 文字的后缀
【发布时间】:2018-04-12 16:16:57
【问题描述】:

似乎没有“J”后缀(la printf 的 %jd)。

那么,是否可以保证 LLULL 后缀适用于 intmax_t 和 uintmax_t 类型?

#include <stdint.h>

intmax_t yuuge = 123456789101112131411516LL;

或者是否有可能存在对于LL 后缀来说太大的文字?比如说,一个具有 32 位 int、32 位长、64 位长、128 位 intmax_t 的(假设的)系统。

【问题讨论】:

  • 详细信息:在 C 中,123 被指定为 constant,而不是 literal。 C 有 2 种文字:字符串文字复合文字。两者都可以获取他们的地址。代码不能取123的地址。不过其他语言确实允许这样做。

标签: c literals


【解决方案1】:

不需要后缀,如果您只想忠实地表示值。 C 语言自动为整数文字提供正确的类型。仅当您想强制文字具有比由于其值而自然具有的更高级别的类型时才需要后缀(例如,1UL 将值 1 作为unsigned long 而不是int,或-1UL作为ULONG_MAX 的替代表达式)。

如果您确实想强制文字具有intmax_t 类型,请使用stdint.h 中的INTMAX_C() 宏。

【讨论】:

    【解决方案2】:

    可能有些文字对于 LL 后缀来说太大了

    是的,如果整数常量超出(u)intmax_t的范围,就太大了,不管有没有LL

    请参阅Assigning 128 bit integer in C 了解类似问题。


    LLLLU 不适用于类型。它们用于整数常量。

    LLL 确保常量的最小 类型。 intmax_t 没有后缀。

    123 is an `int`
    123L is a `long`
    123LL is a `long long`
    123456789012345 is a `long long` on OP's hypothetical system even without LL
    

    intmax_t 可能与long long 具有相同的范围 - 或者可能更宽。 intmax_tlong long 都至少是 64 位的。

    对于启用了良好警告的编译器,如果常量超出intmax_t 范围,则会出现警告。例子:

    //  warning: integer overflow in expression
    intmax_t yuuge1 = (intmax_t)123456*1000000000000000000 + 789101112131411516;
    
    //  warning: overflow in implicit constant conversion [-Woverflow]
    intmax_t yuuge2 = 123456789101112131411516;
    

    C 为最大宽度整数常量提供宏

    以下宏扩展为一个整数常量表达式,其值由其参数指定,类型为 intmax_t:C11 §7.20.4.2 1

    INTMAX_C(value)
    

    INTMAX_C(value) 确实有限制

    这些宏的任何实例中的参数都应该是一个无后缀的整数常量......其值不超过相应类型的限制。

    以下内容在具有 64 位 intmax_t 的机器上不满足该要求。

    // Not so portable code
    intmax_t yuuge = INTMAX_C(123456789101112131411516);
    

    #预处理也仅限于intmax_t

    尝试在(u)int64_t 范围之外创建常量的代码很容易出现可移植性问题。为了可移植性,建议使用另一种编码方法(避免使用如此大的常量)。


    【讨论】:

      猜你喜欢
      • 2011-07-19
      • 1970-01-01
      • 1970-01-01
      • 2019-09-15
      • 1970-01-01
      • 2015-06-21
      • 2014-06-26
      • 1970-01-01
      • 2011-04-03
      相关资源
      最近更新 更多