包括

Question

正如标题中所显示的，我正在质疑在结构中定义宏的原因。我经常在网络编程中看到这种方法，例如在片段之后：

struct sniff_tcp {
    u_short th_sport;               /* source port */
    u_short th_dport;               /* destination port */
    tcp_seq th_seq;                 /* sequence number */
    tcp_seq th_ack;                 /* acknowledgement number */
    u_char  th_offx2;               /* data offset, rsvd */
#define TH_OFF(th)      (((th)->th_offx2 & 0xf0) >> 4)
    u_char  th_flags;
    #define TH_FIN  0x01
    #define TH_SYN  0x02
    #define TH_RST  0x04
    #define TH_PUSH 0x08
    #define TH_ACK  0x10
    #define TH_URG  0x20
    #define TH_ECE  0x40
    #define TH_CWR  0x80
    #define TH_FLAGS        (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR)
    u_short th_win;                 /* window */
    u_short th_sum;                 /* checksum */
    u_short th_urp;                 /* urgent pointer */
};

此示例来自tcpdump网站中的 sniffex.c 代码。

这是为了增强可读性并使代码更清晰。

Answer 1

嗯，定义的常量与其中一个字段的可能值相关。

因此，作者决定改进代码局部性，并使API用户避免在圈内运行。似乎合乎逻辑。

否则，预处理器完全独立于代码。您甚至可以在表达式中放置一个定义。

Answer 2

我们不得不怀疑它正试图向我们传达这些宏只与这个结构中的数据一起使用，但这是一种表达这种情况的糟糕和复杂的方式。

在C ++中，最好使用嵌套的枚举和内联函数来实现这一点，但由于代码是C，宏可能是最好的选择。

在我看来，它降低了可读性，我更愿意看到结构外部的宏，并带有注释，指出它们应该在何处以及如何使用。这样就无法猜测宏的用途是什么，而且结构定义也没有任何缺陷。

Answer 3

一种典型用法如下所示

包括

假设您的第一个版本的foo有点如下所示。

struct foo1 {
 int x;`enter code here`
 ...
};

明天你会尝试以下列方式增强结构

struct foo2 {
 union {
   int x;
   int y;
 } u;
#define x u.x
#define y u.y
};

上述声明不会破坏您所在地的汇编使用了foo_var.x，因为结构foo_var.x的新定义仍然有效且是除了foo_var.u.x

例如用法：

struct foo {
 union {
   int x;
   int y;
 } u;
#define x u.x
#define y u.y
};

int main()
{
  struct foo f;

  f.x = 1;
  f.y = 2;
}

Answer 4

我认为，这不是“最佳实践”，应该在结构附近保留定义（对于值），而不是在结构内部。

（更好的是enum和typedef常量，所以如果没有正确输入，编译器可能会发出警告。）

TH_OFF（）宏是另一种情况，它“隐藏”了另一个元素，所以也许它可以放在这个位置（带有适当的注释）

Answer 5

作者的意图似乎是属于一起的东西应该放在一起。因此，标志宏应位于标志下方。使用相同的逻辑，宏定义与结构声明无关，因此宏不属于那里。将它们放在结构上方或下方没有任何问题。

我想知道如果该标志是一个带有32个标志宏和一些更多其他默认组合宏的u_long，那么作者是否会保持一致并做同样的事情？

在结构体内定义宏的逻辑是什么？

5 个答案:

包括