unsigned 关键字可以以非显而易见的方式使用吗？

Question

每次我使用 unsigned 关键字时，它都会出现在 int 或其他内置类型之前。 我想知道是否还有其他方式可以使用unsigned。

• 用户定义的类型（类/结构）可以使用unsigned关键字吗？
• 模板可以特殊使用unsigned吗？

如果不是，为什么它有自己的关键字？为什么unsigned int 不是uint？

Answer 1

主要问题已经回答了好几次：unsigned 关键字只能用作整型的类型说明符。

至于为什么 unsigned 是一个单独的关键字，而不是一个 uint 关键字，其原因是历史性的。

C 的最早版本（K&R 之前）只有四种基本类型：

• char（8 位，有符号，2 的补码）
• int（16 位，有符号， 2 的补码）
• float（32 位）
• double（64 位，与 float 范围相同，但精度更高）

注意缺少什么：否signed 或 unsigned 关键字，无 short、long 或 long double；所有这些都是后来添加的。 （需要无符号算术的程序员通常使用指针，它们可以与 int 自由互换。）

每个基本类型都有一个作为单个关键字的名称，这使得语法简单明了。

当后来添加其他类型时，将 unsigned、short 和 long 等说明符添加到现有类型名称中而不是引入新的类型是有意义的关键字（可能会破坏现有代码）。当 ANSI C 委员会于 1989 年对该语言进行标准化时，他们必须根据现有的不太正式的定义制定一个连贯的结构，同时与现有的实现保持一致。结果就是我们现在所看到的，其中 int long unsigned long 是一个有效的类型名称（更常见地写为 unsigned long long）。

如果现在从头开始设计该语言，我怀疑会采取不同的方法。也许每个基本类型都有一个关键字（例如，C# 采用的方法），或者基本类型名称可能会使用一些更连贯的方案，而不是一堆关键字（例如，int:2 表示 2 字节整数，unsigned:4 表示 4 字节无符号整数）。但 C 和 C++ 都坚持当前的方法。

参考：http://cm.bell-labs.com/cm /cs/who/dmr/cman.pdf

Answer 2

不，它不能与类或结构一起使用，因为它们不是整型。模板所能做的就是使 int 成为无符号的。我认为它被选为一个单独的关键字，因为它可以应用于任何整数类型（char、int、long、long long），从而用一个关键字实现需要四个关键字的效果。它的含义也很明显，而 uint、uchar 等则不一定。请记住，它也可以在没有限定符的情况下单独使用，在这种情况下，假定为 unsigned int。

Answer 3

unsigned 是一个关键字。 unsigned 只能用于整型 类型。 unsigned 或 signed 被视为类型说明符，简单类型说明符。所以他们指定类型要么是有符号的，要么是无符号的。

您可以通过 typedef 将单词 unsigned int 转换为 uint，但是当 int 为类型和 unsigned 本身就是类型说明符。

与普遍看法相反，您可以单独使用 unsigned，如 C++ ISO 标准第 7.1.5.2 节表 7 所示：

您可以使用多个类型说明符（仅在允许时），并且可以按任何顺序与 decl 说明符自由混合。

您也可以这样做：

int unsigned i;

这是有效的 C++。

Answer 4

No unsigned 本身并不是一个真正的关键字；它只是 int、short、char 的修饰符。

unsigned 关键字可以用作 int、short、 char 或 long。它也可以单独用作类型名称； unsigned 表示unsigned int。

这样做是为了避免使用三个额外的关键字 uint ushort uchar 并且因为在 C 和 Unix 所针对的所有早期计算机上有符号/无符号可能没有不同。

Answer 5

关键字signed、unsigned、short 和long 是类型修饰符/说明符，当这些类型修饰符/说明符之一单独使用时，假定数据类型为int。

因此，signed 和 unsigned 也可以用作独立类型说明符，分别与signed int 和unsigned int 含义相同。以下两个声明是等效的：

unsigned abc;

unsigned int abc;

Answer 6

还有无符号字符。有些编译器，例如 GNU 的 g++，允许您只输入 unsigned 并假设您的意思是 unsigned int。例如以下代码是等效的

unsigned int x;

unsigned x;

Answer 7

SerenityOS 有一篇博客文章介绍了如何将 unsigned 重新定义为 signed，以在标头中实现 size_t：https://awesomekling.github.io/How-SerenityOS-declares-ssize_t/

#define unsigned signed
typedef __SIZE_TYPE__ ssize_t;
#undef unsigned

这可能看起来很黑客，但如果你只支持 GCC/Clang)，它们是唯一实现 的编译器__SIZE_TYPE__，并且需要在没有任何系统库的情况下独立编译（就像内核的情况一样），那么这种定义 ssize_t 的方法是可靠的，而且更可靠比令人讨厌的#ifdef迷宫更容易维护。

为了参考和好奇，让我们研究一下 ssize_t 通常如何/何时在我的 x86_64 Linux Mint 机器上定义。

ssize_t 可以在许多不同的地方按需定义，例如定义 __USE_XOPEN2K8 时的 （旧旧遗留）东西）。但是，ssize_t 定义的主要位置是 /usr/include/x86_64-linux-gnu/sys/types.h 的第 107-110 行，通常将其带入通过包含。以下是第 107-110 行：

#ifndef __ssize_t_defined
typedef __ssize_t ssize_t;
# define __ssize_t_defined
#endif

__ssize_t 来自 /usr/include/x86_64-linux-gnu/bits/types.h 的第 193 行：

__STD_TYPE __SSIZE_T_TYPE __ssize_t; /* Type of a byte count, or error.  */

__SSIZE_T_TYPE 来自 /usr/include/x86_64-linux-gnu/bits/typesizes.h 第 73 行：

#define __SSIZE_T_TYPE      __SWORD_TYPE

__SWORD_TYPE 来自 /usr/include/x86_64-linux-gnu/bits/types.h 的第 115-114 行：

#if __WORDSIZE == 32
# define __SQUAD_TYPE       __int64_t
# define __UQUAD_TYPE       __uint64_t
# define __SWORD_TYPE       int
# define __UWORD_TYPE       unsigned int
# define __SLONG32_TYPE     long int
# define __ULONG32_TYPE     unsigned long int
# define __S64_TYPE     __int64_t
# define __U64_TYPE     __uint64_t
/* We want __extension__ before typedef's that use nonstandard base types
   such as `long long' in C89 mode.  */
# define __STD_TYPE     __extension__ typedef
#elif __WORDSIZE == 64
# define __SQUAD_TYPE       long int
# define __UQUAD_TYPE       unsigned long int
# define __SWORD_TYPE       long int
# define __UWORD_TYPE       unsigned long int
# define __SLONG32_TYPE     int
# define __ULONG32_TYPE     unsigned int
# define __S64_TYPE     long int
# define __U64_TYPE     unsigned long int
/* No need to mark the typedef with __extension__.   */
# define __STD_TYPE     typedef
#else
# error
#endif

__WORDSIZE 来自从 /usr/include/x86_64-linux-gnu/bits/wordsize.h 第 3-9 行

#if defined __x86_64__ && !defined __ILP32__
# define __WORDSIZE 64
#else
# define __WORDSIZE 32
#define __WORDSIZE32_SIZE_ULONG     0
#define __WORDSIZE32_PTRDIFF_LONG   0
#endif

： __x86_64__ 和 __ILP32__ 都是编译器提供的预定义宏，并从根据源代码构建编译器的 makefile 中烘焙到编译器的二进制文件中。

/usr/include/x86_64-linux-gnu 下的所有文件都特定于我的计算机的本机 x86_64 架构，并且 x86_64 专门是 x86 ABI 的 SysV 64 位扩展。

检查 定义的 __x86_64__ &&仅当将 x86_64 编译器与 -m32 或 -mx32 一起使用以强制其分别生成 32 位或 x32-abi 代码时，!define __ILP32__ 才为 false 。然而，编译 32 位二进制文​​件的更常见方法是安装相应的 GCC 多架构编译器。

为了进行比较，musl libc 采用更短的路径，仅在特定于体系结构的标头基础上将所有类型定义为其各自的固定宽度整数。对于 x86_64： https://git.musl-libc.org/cgit/musl/tree/arch/x86_64/bits/stdint.h?id=3f08154ac494f4739afbc7451f317b2ef1bffbd3