class A {
// Methods
#ifdef X
// Hidden methods in some translation units
#endif
};
这是否违反了类的单一定义规则？相关的危险是什么？ 如果使用成员函数指针或虚函数，很可能会出现问题。否则，可以安全使用吗？
我正在考虑在 Objective C++ 的上下文中使用它。头文件包含在纯 C++ 和 Objective C++ 翻译单元中。我的想法是使用 OBJC 宏来保护带有 Objective-C 类型的方法。否则，我必须在头文件中为所有 Objective-C 类型使用 void 指针，但这样我会失去强类型，并且还必须在整个代码中添加丑陋的静态转换。
是的，如果允许不同编译单元具有不同状态的宏定义X，则可能会导致ODR违规的危险。在包含该类定义之前，程序（及共享对象）应在全局范围内定义（或未定义）X以满足要求。就C++编译器而言（而不是预处理器），这些是两个不同、不兼容、不相关的类类型。
想象一种情况，在编译单元A.cpp中，在class A之前定义了X ，而在单元B.cpp中未定义X。如果在B.cpp中没有使用那些被“删除”的成员，则不会收到任何编译器错误。两个单元都可以被认为是良好形式的。现在，如果B.cpp包含新表达式，则会创建一个大小较小的不兼容类型的对象。但是，来自class A的任何方法，包括构造函数，都可能由于使用更大的定义而在使用在B.cpp中创建的对象时访问对象存储外的内存而导致UB。
这种错误的变体是，在构建树的两个或多个不同文件夹中包含标题文件副本，它们具有相同的文件名和POD结构类型，其中一个文件夹可以通过#include <filename>访问。 使用#include "filename"的单元应该使用替代方案。 但是它们不会。因为在这种情况下，头文件查找的顺序是平台定义的，程序员无法完全控制每个平台上哪个头文件将包含在哪个单元中#include "filename"。 一旦一个定义发生了变化，即使仅重新排序成员，ODR也会遭到破坏。
为了特别安全起见，这些事情应该只在编译器领域中使用模板、PIMPL等完成。对于跨语言通信，应使用包装器或适配器来进行中间处理，因为C++和ObjectiveC++可能具有非POD对象的不兼容内存布局。
vtable的大小和完整性是另一个可能的问题。离题了，但为什么编译器在链接期间会选择3个函数（a+b+c）而不是2个函数（a+c）的vtable？我想vtable必须满足ODR，所以我们讨论UB，因此无法确定b()调用是否为c()调用或c()是否尝试执行不存在的函数。 - R2RT// a.h
class Foo
{
public:
Foo() { ; }
#ifdef A
virtual void IsCalled();
#endif
virtual void NotCalled();
};
第一个 C++ 文件：
// a1.cpp
#include <iostream>
#include "a.h"
void Foo::NotCalled()
{
std::cout << "This function is never called" << std::endl;
}
extern Foo* getFoo();
extern void IsCalled(Foo *f);
int main()
{
Foo* f = getFoo();
IsCalled(f);
}
第二个 C++ 文件：
// a2.cpp
#define A
#include "a.h"
#include <iostream>
void Foo::IsCalled(void)
{
std::cout << "We call this function, but ...?!" << std::endl;
}
void IsCalled(Foo *f)
{
f->IsCalled();
}
Foo* getFoo()
{
return new Foo();
}
结果：
该函数从未被调用
糟糕！代码调用了虚函数IsCalled，但由于两个编译单元在类虚函数表中的条目位置存在分歧，我们派发到了NotCalled。
这里出了什么问题？我们违反了ODR。因此，现在两个编译单元在虚函数表中的位置发生了争议。因此，如果我们在一个编译单元中创建一个类并从另一个编译单元调用其中的虚函数，则可能会调用错误的虚函数。哎呀哇！
请不要故意做那些相关标准说不允许且行不通的事情。你永远无法想到每种可能出错的方式。这种推理已经在我几十年的编程生涯中引起了许多灾难，我真希望人们能停止故意和有意地制造潜在的灾难。
在C++类成员函数中使用#ifdef守卫是否安全？
实际上（使用GCC作为 g++ -O2 -fverbose-asm -S 查看生成的汇编代码），你提出的方法是安全的。理论上不应该这样做。
int dontuseme(void)那样带有dontuse），并编写GCC插件以在编译时发出警告。或者在构建过程中（例如在您的Makefile中）使用一些聪明的grep(1)。
另外，您的GCC插件可以实现新的#pragma或函数属性，并警告不当使用这些函数。
当然，您也可以（巧妙地）使用private:，最重要的是，在您的构建过程中生成C++代码（使用类似SWIG的生成器）。
_5yQcFbU0s（在RefPerSys中完成）的“随机”C ++标识符（或C标识符，或ObjectiveC ++名称等），那么名称的意外碰撞就非常不可能。
在评论中，您说：inline C ++函数（使用reinterpret_cast），以再次获得强类型。 Qt也这样做！ FLTK或FOX或GTKmm也会生成C ++代码（因为GUI代码很容易生成）。还必须在代码中添加不美观的静态转换
例如，RPCGEN 和 SWIG - 或者 Bisoncpp- 会生成丑陋的 C 和 C++ 代码，但它们非常有效（也许还有一些专有的 ASN.1 或 JSON 或 HTTP 或 SMTP 或 XML 相关的内部代码生成器）。
一个用于C ++，另一个用于Objective C ++。 SWIG 工具可能会启发您。当然，您的（C或C ++或Objective C）代码生成器将发出随机的标识符....就像我在Bismon中做的那样（生成随机的C名称，例如moduleinit_9oXtCgAbkqv_4y1xhhF5Nhz_BM）和RefPerSys（生成随机的C ++名称，如rpsapply_61pgHb5KRq600RLnKD ...）; 在两个系统中，意外的名称冲突非常不可能发生。
#ifdef守卫不安全，正如这个答案中所解释的那样。PS. 几年前，我曾经在GCC MELT上工作，为一些旧版本的GCC编译器生成了数百万行的C++代码。今天-2021年-您几乎可以直接使用asmjit或libgccjit来生成机器码。部分求值是一个很好的概念框架。
private:不可以做到吗？你要把它们隐藏在谁的视线之外，因为拥有该文件的任何人都可以读取它？ - Aganju