具有预处理器分支实现的结构是否存在ODR违规？

Question

In a project that uses both C and C++, a .h file contains a definition of a type. If that definition depends on whether the header is included by c or cpp files, am I violating the one definition rule?

// my_header.h
struct MyStruct
{
#ifdef __cplusplus
    std::size_t member; 
    int surprise; 
#else
    unsigned member; 
#endif
};

I know that ODR has to do with different translation units, but in "my case" won't different translation units end up having different implementations for a common struct? I've seen this in production code and initially I was wondering what is the linker doing in this case.

Any thoughts?

Answer 1

As long as you use one compiler (C or C++), you won't have a problem. It doesn't matter what extension the header files have.

But if you're linking together translation units from different languages, then yes you're violating the ODR.

Overall this just seems really error prone. I'd give the C++ type an entirely different name. You can use your macro to switch between the two, perhaps using the preprocessor around a typedef ?

Answer 2

There are two cases:

• All the translation units that include the header (for a given program) are compiled as the same language (C or C++):

  ==> No problems.

• Some translation units that include the header are translated as C, some are translated as C++.

  ==> ODR violation.

However, ODR violation is only "undefined behaviour", and actually, there isn't all that much which is defined in the standards about linking C and C++ together (except some vague suggestion "it ought to work"). In other words, if you are linking C and C++ together, you are probably depending on the details of your implementation anyway.

In general, if you are compiling 32-bit (so that std::size_t and unsigned are the same size), and provided that C++ does all the allocation, and provided that you never deal in arrays of these things in C, you will probably get away with it.

Answer 3

Yes, I have a thought (hey, sorry, you asked): please don't write code that way. Okay I'll reserve the correct way to do this till the end. But as far as your question goes: yes, this will result in ODR violations if you use both a C and a C++ compiler as part of your build process. The actual file extension may be irrelevant (it may change defaults for the compiler, but your build system may explicitly specify the language the compiler). That said, this is a pretty bad idea and pretty unusual, because C is so close to being a proper subset of C++, that it would be much more common to simply write C code that can also build with a C++ compiler. And in the projects that have both C and C++ components, you would use a C++ compiler, and in projects that are pure C, you could still use that code. So, regardless of file extension, this is fine as long as a given project sticks to only one compiler.

// my_header.h
#ifdef __cplusplus
    constexpr bool is_cpp = true;
#else
    constexpr bool is_cpp = false;
#endif

struct cpp {
  std::size_t member;
  int surprise;
};

struct cc {
  unsigned member;
};

template <bool CPP>
struct MyStructImpl : private std::conditional_t<cpp, cc, CPP>
{
};

using MyStruct = MyStructImpl<is_cpp>;

This keeps as much code as possible in structs that are defined the same way and unconditionally regardless of macro options, and defers the macro related stuff to as late as possible. This is also a big win in terms of tooling and testing, eg you can run unit tests for both versions of your struct without recompiling.

Answer 4

It's not clear to me what violating the ODR means when you're linking multiple languages together; the C++ standard has nothing to say about what struct s you can define in your C object files. We are thus forced to answer in "assembly terms" (based on common implementations), in which case the answer (as has been given more eloquently already) is wat .