typedef 结构：未知名称答案

【问题标题】：typedef struct: unknown nametypedef 结构：未知名称
【发布时间】：2020-06-05 05:57:13
【问题描述】：

我对我的实际问题感到困惑......也可能是我的错误

带代码的简短说明：

rtc.h

#ifndef RTC_H_
#define RTC_H_

typedef struct timestamp_t
{
    uint8_t year,month,day,hour,minute,second;
}timestamp_t;

#endif /* RTC_H_ */

lpwa.h

#ifndef LPWA_H_
#define LPWA_H_

#include "rtc.h"

timestamp_t lpwa_ntp_to_stamp(char*); //shows error: unknown name timestamp_t

#endif /* LPWA_H_ */

lpwa.c

#include "lpwa.h"

timestamp_t lpwa_ntp_to_stamp(char *text) //no problem
{
    ...
}

如果我将 typedef 结构复制到 lpwa.h，它会显示“timestamp_t 的冲突类型”

是我遗漏了什么还是这不可能？

【问题讨论】：

显示的代码不应该出现。但是显示的代码不是您使用的（从语法破坏... 来看）。抱歉，如果这听起来很迂腐，但请仔细检查您所显示的内容是否真的是 minimal reproducible example，它证明了您的问题。我怀疑在此处不可见的某处存在隐藏或间接的附加 #include。
请将这样的行插入到两个相关的头文件中。 #error Header A is compiled（第二个是“A”->“B”）。这将允许您确定包含的顺序（假设它比此处显示的更复杂）并确保您正在查看的文件确实是编译器包含的文件。这是调试过程中广泛传播的错误，不是想取笑你....
谢谢！这实际上是一个大程序，因此逐步删除东西将是巨大的负担。我想知道是否有人知道导致此问题的“常见错误”。
常见错误：另一个 c 文件包含的内容与您想象的不同。其中一个标题包含的另一个标题与您想象的不同。您正在查看的文件不是构建期间使用的文件。以上所有......我的第二条评论描述了如何调试它。制作 MRE 并不一定意味着从整个程序中删除一些东西（尽管这是建设性的前进方式）。您可以从最后开始，对您认为发生的事情进行 MRE，但是它可能会表明问题并不像您想象的那样存在。将其用作有用的信息需要经验...
如果您在最后开始您的 MRE，您需要积极尝试引发您看到的问题。试试这个：在执行 typedef 之前，从 rtc.h 中包含 lpwa.h。我认为这可能会让你在所示的 MRE 中出现描述的错误。如果这是真的，请尝试在您的实际代码中找到包含。您可能只是在制作此处显示的 MRE 时错过了它。

标签： c struct typedef

【解决方案1】：

这是根据我的调试建议编译的答案，它帮助 OP 找到了实际问题：

显示的代码不应出现所描述的问题。这实际上是有用的信息，因为这意味着您的实际代码的结构是不同的，您需要找到差异来追踪问题的根源。
问题可能在于包含顺序，也就是包含树，与您想象的不同。
在项目的所有可能和不太可能的地方慷慨地插入#error Header A is compiled#error Header B is compiled 将使您了解实际的包含树，从而使您能够寻找与想象的包含树的差异。（如果您的编译器支持，请使用#warning，那么您获得的不仅仅是遇到的第一个#error。）
调试此问题的建设性方法是制作 StackOverflow 风格的最小可重现示例。
如果制作经典的 MRE/MCVE (http://stackoverflow.com/help/mcve) 看起来工作量太大（相信我，事实并非如此），那么请尝试从头开始制作您认为发生的事情的 MRE。这至少会告诉你，你认为发生的事情并不是实际发生的事情。这也是有用的信息，尽管使用它需要经验和纪律。（感谢您在这里没有感到被嘲笑。）
请记住，每个源代码文件“*.c”都是另一个包含树的根。
使用#error 还会提醒您查看的文件可能与编译器实际处理的文件不同（例如在您的编辑器中）。（再说一遍，不是嘲讽。对我来说，这种情况发生的频率比我想承认的要多......）

以上是通用的。

特别是在您的情况下，我怀疑在显示的包含和显示的 typedef 之间存在 rtc.h 中的隐藏/间接#include "lwpa.h"。（我想你已经证实了这一点。）

【讨论】：

@DavidC.Rankin 我知道你的同事。但是请尝试写评论[mre]。我相信这意味着 MRE 在 StackOverflow 上是官方的。当然[mcve] 也可以。
@DavidC.Rankin 确实使用了您的链接。感谢您的意见。
@DavidC.Rankin 我在这里看到了你的贡献。您的赞美至少与我得到的支持一样受到赞赏（与其中一个是否来自您无关。）
像你这样的人少了会很伤心。玩得开心。试着给予你感激的东西。
这就是您建立社区并帮助下一代学习编码的方式——正确..