【问题标题】:Gcc: force compiler to use unsigned char by defaultGcc:强制编译器默认使用无符号字符
【发布时间】:2013-12-29 09:21:36
【问题描述】:

由于 C++ 中 char 的性质在 unsigned 限定符不存在时依赖于编译器,所以我是否可以将一个参数传递给 GCC 来强制所有 @987654323 @s 编译为unsigned?

【问题讨论】:

  • 我通过谷歌搜索gcc force unsigned char 在十秒钟内发现了这一点,然后阅读了出现的 GCC 文档。是什么阻止了您进行这项研究?
  • @LRO,因为你显然比通过谷歌拖网要快得多...... ;)
  • 使用unsigned char 可能比简单的char 更好。您的程序可能会链接到在没有-funsigned-char 的情况下编译的代码。如果您依赖无符号字节,则在代码中而不是在编译器选项中表达它更安全。
  • @Keith -- 这是我在这里读到的最疯狂的评论。纯文本 ascii 文件不知道字节是有符号还是无符号,更不用说内存了。某些平台默认将 char 设置为 unsigned。 char 数据类型规范被编写为对开始时的签名不是很特别。
  • @B.Nadolson:如果您认为我的 cmets 是最疯狂的,那您一定没有读过很多 cmets。问题不是关于 ASCII 文本文件,而是关于类型 charchar 类型 对它的签名非常特别。在某些实现上,它是特别签名的;在其他人身上,它特别没有签名。如果签名很重要,您应该使用signed charunsigned char;这就是它们存在的原因。

标签: c++ gcc char unsigned


【解决方案1】:

您要查找的标志是-funsigned-char

来自the documentation

-funsigned-char

char 类型为无符号,如unsigned char

每种机器都有一个默认的char 应该是什么。它要么默认像unsigned char,要么默认像signed char

理想情况下,可移植程序在依赖于对象的签名时应始终使用signed charunsigned char。但是许多程序被编写为使用普通的char 并期望它被签名,或者期望它未被签名,这取决于它们被编写的机器。此选项及其反选项使您可以使此类程序以相反的默认值运行。

char 类型始终与 signed charunsigned char 中的每一个都不同,即使它的行为总是与这两者中的一个类似。


-fsigned-char

char类型被签名,比如signed char

注意这等价于-fno-unsigned-char,是-funsigned-char的否定形式。同样,选项-fno-signed-char 等价于-funsigned-char

影响chartypes like wchar_t are unaffected.

【讨论】:

  • 你能确认这个标志对wchar_t的签名没有影响吗?
  • @Antonio:不知道,抱歉。
  • @Antonio: Yes.
【解决方案2】:

您可以为此使用-funsigned-char,或使用-fsigned-char 进行签名。

【讨论】:

    【解决方案3】:

    您可以使用选项:-funsigned-char

    source

    【讨论】:

      【解决方案4】:

      正如其他答案所说,gcc 的 -funsigned-char 选项强制普通 char 未签名。

      但这可能不是解决您的问题的最佳方法。您需要无符号字符,但是通过使用特定于编译器的选项,您可以在构建命令(Makefile、构建脚本或您键入的用于编译代码的命令)中对该信息进行编码。如果程序的语义依赖于无符号字符,最好在源代码中记录该信息。它更清晰,并且减少了有人错误地构建您的程序的机会。

      如果你想要无符号字符,使用unsigned char。如果您想要签名字符,请使用signed char。如果您只需要字符,并且您确定程序的行为不取决于它们是有符号还是无符号(例如,如果所有存储的值都在 0..127 范围内),请使用 char

      【讨论】:

        【解决方案5】:

        没有足够的声誉来评论@Keith 的回答。

        我看到使用-funsigned-char-fsigned-char 的主要原因是当你想要以下代码时

          printf("%d\n",'\x80');
        

        显示-128128

        关于不依赖特定编译设置的评论是有效的,但这里有点简化现实。主要问题是出于效率原因,C 将语言的某些部分留给了实现,通常您希望调整该实现以最适合您的应用程序。在我看来,专业开发人员应该始终检查所有编译器标志并选择最适合他的需要。如果您依赖某些特定设置,您的单元测试当然会涵盖这种情况,或者断言它。如果您移植应用程序,您将查看原始移植的编译设置。

        【讨论】:

        • “TMO”代表什么?
        • 我明白了。我不熟悉这种结构。对我来说似乎也不符合语法。这是什么意思?
        • 经过一番谷歌搜索后,执行 s/to/in/ 可能对您来说更清楚。事实证明我多年来一直在使用它,但确实是不正确的。感谢您指出!
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-03-09
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-01-12
        相关资源
        最近更新 更多