[C++] Allow C++/CLI projects to build with Arrow​

[asfimport]

Currently, the inclusion of in some of Arrow's C++ headers prevents C++/CLI code from building against it.

From a C++/CLI project:

#include <arrow/io/file.h>
...

"#error directive: is not supported when compiling with /clr or /clr:pure."

This could be patched by optionally relying on Boost's mutex/lock_guard instead of std, or not exposing the #include publically.

Reporter: Toby Shaw
Assignee: Wes McKinney / @wesm

Related issues:

• [C++] Do not include in public headers (is related to)

PRs and other links:

• GitHub Pull Request #1098
• GitHub Pull Request #1228
• GitHub Pull Request #1098
• GitHub Pull Request #1228

_{Note: This issue was originally created as ARROW-1134. Please see the migration documentation for further details.}

[asfimport]

Uwe Korn / @xhochy:
[~tobyshaw] I would be in favour here to not expose the #include <mutex> publicly. This won't be straightforward as you would need to write private implementations then for some of the classes. Alternatively in some cases, we probably could implement functions without a mutex, e.g. https://github.com/apache/arrow/blob/master/cpp/src/arrow/io/memory.cc#L152 could be refactored to be lock-free. Can you make a patch for that?

Is there a list showing what is disallowed in C++/CLI?

[asfimport]

Toby Shaw:
I agree that is probably the most sensible way to fix this.

As for the list, sadly I don't believe there exists one (if there is I would love to know about it). It's a fair point that simply hiding the mutex includes might not necessarily resolve all of the restrictions on C++/CLI. Having said that, I locally resolved the mutex issue by using Boost's headers instead, and there was one complaint about a nullptr (fixed by replacing it with NULL), and after that it worked fine. Of course I haven't touched the entire Arrow API, so certainly more digging might be needed.

[asfimport]

Uwe Korn / @xhochy:
It would be nice if we would have a compile check in our AppVeyor CI build that tests if you can use the Arrow API in C++/CLI.
Note that you should be able to include all public Arrow headers in your code by #include <arrow/api.h>

[asfimport]

Wes McKinney / @wesm:
I'm OK with hiding mutexes in private implementations where needed

[asfimport]

Toby Shaw:
@xhochy Somewhat tangential, but I'm not sure where else to post this.

You mention all public Arrow headers can be included via #include <arrow/api.h>. Unless I'm mistaken, this doesn't seem to include arrow/io/file.h, which is included in parquet-cpp, see: https://github.com/apache/parquet-cpp/blob/master/src/parquet/file/reader.cc#L26. Should parquet depend on non-public Arrow headers?

[asfimport]

Wes McKinney / @wesm:
That's an artifact of that fact that libarrow used to be 3 libraries (libarrow/libarrow_io/libarrow_ipc). We should clean up the "api.h" files

[asfimport]

Toby Shaw:
I mentioned earlier about C++ CLI complaining about nullptr usage. C++ CLI already had a nullptr keyword when C++11 introduced its own. This leads to incompatibilities when building with native projects which use nullptrs in header files.

Annoyingly, the nullptrs which exist in header files are as default arguments, which need to live in headers. The recommended fix is to use __nullptr instead of nullptr, but I'm not sure if that is valid C++ outside of Visual C++

(All these changes also apply to parquet-cpp)

[asfimport]

Wes McKinney / @wesm:
Is there some way to detect C++CLI with an ifdef?

[asfimport]

Toby Shaw:
__cplusplus_cli seems to work, I'll do that.

[asfimport]

Wes McKinney / @wesm:
[~tobyshaw] marked for 0.6.0. Would you be able to submit a patch?

[asfimport]

Wes McKinney / @wesm:
Issue resolved by pull request 1228
#1228