使用指向结构内部声明的字段的指针（也称为 CONTAINING_RECORD 宏）来计算指向整个结构的指针的可移植方法

例如，在 Winnt.h 中定义了众所周知的 CONTAINING_RECORD() 宏：

#define CONTAINING_RECORD(address, type, field) ((type *)( \
                                              (PCHAR)(address) - \
                                              (ULONG_PTR)(&((type *)0)->field)))

或者在 FreeBSD 中：

#define CONTAINING_RECORD(addr, type, field)    \
      ((type *)((vm_offset_t)(addr) - (vm_offset_t)(&((type *)0)->field)))

或者在 Linux 中：

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
#define container_of(ptr, type, member) ({                      \
      const typeof(((type *)0)->member) * __mptr = (ptr);     \
      (type *)((char *)__mptr - offsetof(type, member)); })

当然，在世界上许多其他地方也是如此。

但是，我怀疑它们是否符合标准。

增强源（boost _1_48_0/boost/intrusive/detail/parent_from_meber.hpp）而不是 让我失望 - 他们有 3 个 #ifdef PARTICULAR_COMPILER 案例：

template<class Parent, class Member>
inline std::ptrdiff_t offset_from_pointer_to_member(const Member Parent::* ptr_to_member)
{
   //The implementation of a pointer to member is compiler dependent.
   #if defined(BOOST_INTRUSIVE_MSVC_COMPLIANT_PTR_TO_MEMBER)
   //msvc compliant compilers use their the first 32 bits as offset (even in 64 bit mode)
   return *(const boost::int32_t*)(void*)&ptr_to_member;
   //This works with gcc, msvc, ac++, ibmcpp
   #elif defined(__GNUC__)   || defined(__HP_aCC) || defined(BOOST_INTEL) || \
         defined(__IBMCPP__) || defined(__DECCXX)
   const Parent * const parent = 0;
   const char *const member = reinterpret_cast<const char*>(&(parent->*ptr_to_member));
   return std::ptrdiff_t(member - reinterpret_cast<const char*>(parent));
   #else
   //This is the traditional C-front approach: __MWERKS__, __DMC__, __SUNPRO_CC
   return (*(const std::ptrdiff_t*)(void*)&ptr_to_member) - 1;
   #endif
}

第二种情况（#if Defined GNUC and other））似乎是最常见的，但我不确定带有“零初始化”父级的指针算术是否定义良好（？）

所以我的问题是：

1. CONTAINING_RECORD 又名container_of 宏实现中至少之一是否符合标准？

2. 如果没有，是否存在一种符合标准的方法来使用指向结构内部声明的字段的指针来计算指向整个结构的指针？

3. 如果没有，是否存在一种实用的便携式方法来做到这一点？

如果 C 和 C++ 的答案不同，我对这两种情况都感兴趣。

1. 不，您提供的都不符合要求。取消引用空指针不是，typeof不是并且({ ... })表达式不是。

2. 是的，linux 的第二部分已正确重写(type *)((char *)(ptr) - offsetof(type, member))是合规的。 (offsetof标准中定义）

3. see 2

AFAIK，所有这些对于 C 和 C++ 都有效

Edit:linux 试图通过检查指向成员的指针和参数中的指针是否兼容赋值来为宏添加额外的安全性。据我所知 gcc 扩展typeof对于 C 中的这种方法至关重要。

对于 C99，您可以使用“复合文字”通过执行类似的操作来进行稍弱的检查

(type){ .member = *(ptr) }

但这只会告诉你如果类型*ptr赋值是否兼容member。例如如果ptr将会float*和会员double这仍然有效。

无论如何，类型检查只会给您带来虚假的安全性。你一定非常确定你的ptr真正来自内心type使用这个。当心。

Edit:正如 bert-jan 在下面的评论中所说，在 C++ 中，当存在虚拟继承时，offsetof宏的根本问题是无法在编译时确定成员的偏移量。我不相信当前容器宏的想法在这种情况下有任何意义。是极其小心。