使用LASlib时BOOL typedef重新定义

BOOL typedef redefinition when using LASlib

本文关键字：定义 新定义 LASlib BOOL typedef 使用      更新时间：2023-10-16

这个问题看起来可能很熟悉，但我认为它与之前就同一主题提出的问题仍然有些不同(尽管"解决方案"可能是相同的，即除了干扰第三方代码库之外，没有真正的解决方案(

如下：

一个可移植的C/C++框架构建在Linux和Windows上。它利用

  • 微软C类型BOOL，它包含在winwinde.h中，是Windows平台SDK的一部分。基础类型是"int"，如果将值"1"定义为">TRUE"，将值"0"定义为">FALSE'，则这是有意义的。

    #ifdef __cplusplus
extern "C" {
#endif
...
typedef int                 BOOL;
...
#endif

  • 通过预处理器分支，对于linux，BOOL被合理地类型定义为int(确切地说是int32_t(，以保持数据表示之间的字节大小一致性。(我知道，这还不够，并且交换了地方性，但大多数代码仍然很简单。(

    typedef int32_t             BOOL;

此平台代码是专有的(我是作者(，因此可以进行更改。

当下游lib或应用程序希望在https://github.com/LAStools/LAStools/tree/master/LASlib编译器标记冲突的BOOL类型，因为LASlib包含一个名为"mydefs.hpp"的文件，当在Windows下编译时，该文件使用int作为底层类型，但对于linux，似乎更喜欢C++的"BOOL"。

#if defined(_MSC_VER) && (_MSC_VER < 1300) || defined (__MINGW32__)
typedef int                BOOL;
#else
typedef bool               BOOL;
#endif

我不是微软用户，但这完全是倒退的(另请参阅在C中使用布尔值(。我可以想象，linux代码生成的数据片段较小，平台分支随处可见，但imho应该留给编译器。此外，我不应该操纵预处理器保护程序(这会在CMake领域造成混乱(，所以我有点纠结于此。

所以现在我面临着一个进退两难的境地；

  • 更改LASlib代码(我不喜欢，它应该是第三方(
  • 假设整个框架的BOOL在linux中应该是'BOOL'，但这意味着将C++类型构造映射到C类型，放弃数据大小稳定性，显然明天另一个lib可以将其重新键入为PlanetCokooDevice类类型，所以它不能解决真正的问题

我已经阅读了不同类型的Typedef重定义('；signed char'；vs'；bool'；(和包含minwindedf.h之后的bool重定义的答案，但我觉得问题更严重。

那么，在全局命名空间中，甚至在"C"级别上，是否存在某种冲突类型的包罗万象？LASlib是一个只有C++头的lib，但我也不能将整个东西外部化为"C"。

似乎没有"真正的"解决方案，即如果全局命名空间中的双类型定义都在(单独的(第三方库中定义，并且您希望将它们作为依赖项传递给下游项目，则它们将发生冲突。它们应该由各自的作者命名。

我目前的"解决方法"是通过确保我对BOOL的使用仅限于windows代码来避免这个问题，即将特定于平台的部分移动到#ifdef防护后面。在某些情况下，这意味着包装/重新键入函数返回值只是因为。丑陋，但它是有效的。

相关文章：