Golang 中的 *uint 和 uintptr 有什么区别？

Question

我们提供了以下整数类型：int  int8  int16  int32  int64uint uint8 uint16 uint32 uint64 uintptr理论上，这意味着我们还可以拥有指向所有这些类型的指针，如下所示：*int  *int8  *int16  *int32  *int64*uint *uint8 *uint16 *uint32 *uint64 *uintptr如果是这种情况，那么我们已经有了一个指向 *uint 形式的 uint 的指针。这将使 uintptr 变得多余。官方文档并没有对此给出太多说明：uintptr is an integer type that is large enough to hold the bit pattern of any pointer.据我了解，这意味着 uint 的位宽是在编译时根据目标体系结构（通常是 32 位或 64 位）确定的。指针宽度也应该缩放到目标体系结构似乎是合乎逻辑的（即：32 位 *uint 指向 32 位 uint）。Golang 也是这样吗？另一个想法是，也许添加 uintptr 是为了使在进行多重间接寻址时语法不那么混乱（即：foo *uinptrvs foo **uint）？我最后的想法是，也许指针和整数在 Golang 中是不兼容的数据类型。这将是相当令人沮丧的，因为硬件本身并不区分它们。例如，“分支到此地址”指令可以使用来自刚刚在“添加此值”指令中使用的同一寄存器的相同数据。uintptr 的真正意义是什么（双关语）？

Answer 1

您正在混淆 uintptr 和 *uint。uintptr 在处理指针时使用，它是一种足够大以容纳指针的数据类型。它主要用于不安全的内存访问，查看unsafe包。*uint 是指向无符号整数的指针。

Answer 2

简短的回答是“从不使用uintptr”。😀

长的答案是，uintptr是否可以绕过类型系统并允许 Go 实现者在 Go 中编写 Go 运行时库（包括垃圾收集系统），并调用 C 可调用代码，包括使用不被处理的 C 指针的系统调用。去吧。

如果您作为实施者（例如，提供对新操作系统上的系统调用的访问），您将需要uintptr. 您还需要了解使用它所需的所有特殊魔法，例如，如果操作系统要对操作系统级线程执行堆栈式操作，则将 goroutine 锁定到操作系统级线程。（如果您将其与 Go 指针一起使用，您可能还需要告诉编译器不要移动您的 goroutine 堆栈，这是通过特殊的编译时指令完成的。）

运行时系统将 anunsafe.Pointer视为对对象的引用，这使对象在 GC 中保持活动状态。它不认为 auintptr是这样的参考。（也就是说，虽然unsafe.Pointer有指针类型，但uintptr有整数类型。）

Answer 3

uintptr 只是内存地址的整数表示形式，无论它指向的实际类型是什么。有点像void *C 语言，或者只是将指针转换为整数。它的目的是用于不安全的黑魔法，并且不会在日常的 go 代码中使用。