c++ - 如何最好地防止库(源)和应用程序(头文件)编译之间的(编译器)标志不匹配？

Question

在实现头文件中给出的某些接口(interface)时，如何最好地防止库实现的编译与头文件之间的危险不匹配？

详细信息:库接口(interface)由头文件提供，例如 foo.h , 以及它由一些源文件实现，比如 foo.cc .后者被编译以创建库，例如 libfoo.so , 而前者 #include<>由应用程序编辑，该应用程序链接到 libfoo.so .

现在，假设在 foo.h

// foo.h
namespace foo {
  class bar
  {
#ifdef SomeOption
    std::int32_t x[2];
#else
    std::int64_t x[2];
#endif
    bar const*ptr;
    /* ... */
  };
}

然后是ptr的偏移量是 8 字节还是 16 字节，取决于 SomeOption (并且 sizeof(bar) 也不同)。现在，如果库是用不同的值编译的 SomeOption比应用程序，那么显然会出现严重的问题(对于不知情的人来说很难调试)。

一个解决方案？所以，我想到了以下想法

// foo.h
namespace foo {
  enum { hasSomeOption = 1 };
  int options_flags()
  {
    return 0
#ifdef SomeOption
    | hasSomeOption
#endif
    ;
  }
  class bar
  {
    /* ... as before */ 
    bar(some_args, int);
  public:
    bar(some_args) : bar(some_args, options_flags()) {} // what's option_flags()?
    /* ... */
  };
}

和

// foo.cc
namespace {
  const int src_flags = options_flags(); // flags used for compiling library source
}
namespace foo {
  bar::bar(some_args, int app_flags)
  {        
    assert(app_flags == src_flags);
    /* ... */
  }
}

认为 assert会发现任何不一致之处。但是，这不起作用:编译器似乎优化了我的想法并且断言永远不会触发，即使 SomeOption 也是如此。曾是库和应用程序编译不同。

问题是否有推荐的解决此类问题的最佳方法？

Answer 1

我希望有更好的方法，但您始终可以根据选项更改类或命名空间名称，这样如果有人使用了错误的编译器选项 - 将找不到该类。

更改 namespace 的名称似乎更好——在使用调试器时不会造成很多困惑。像这样:

#ifdef SomeOption
    #define foo foo_32bit
#else
    #define foo foo_64bit
#endif

namespace foo
{
 ....
}

我想它会起作用，但确实很难看。