We have 2 applications that are part of our product, one is written in native C++ and lives in its own solution, and the other is a C# application in its own solution. Both solutions are in the same repository, and we are planning to introduce a database that both of these solutions will be using.

There is a discussion happening now internally in our software team on whether we should be sharing an enum that will go into the database between the 2 languages by using ifdefs... So the proposal from one side is to do something like this:

```cpp
#undef ENUMKEYWORD
#undef ENUMNAMESPACE

#if !__cplusplus
#define ENUMKEYWORD public enum class
#define ENUMNAMESPACE EnumShareManaged
#else
#define ENUMKEYWORD enum class
#define ENUMNAMESPACE EnumShare
#endif

namespace ENUMNAMESPACE
{
  ENUMKEYWORD MyEnum
  {
    a = 1,
    b = 2,
    c = 3,
  };
}

```

I argued that this is a terrible idea with little benefit. My reasoning in no particular order:

* These are 2 different applications written in 2 different languages
* Doing this creates a hidden dependency between these solutions and they will lose their "independence"
* The database should be the final source of truth regarding the up-to-date enum
	+ Even if Sqlite doesn't support enums, and we'll have to create many tables for all of our enums, it's not the point
* Complicates our (already complex) solution and build process even more
* If other parts of the database change, then we would have to update both solutions anyway.

My proposal is 2 enums, one in C++ and the other in C#, and then writing an integration test to ensure they stay in sync and adding comments to remind developers about the other enum.

Maybe if there was an elegant solution using C++/CLI somehow in the middle, we could try that, but I think creating some `enum.cs.h` with preprocessor definitions is just ugly and terrible software architecture...

Thoughts?