0

I intend to use a c++ lib from a dotnet core application. I am trying to create a Wrapper around this c++ lib.

The class I try to wrap is Client ( see : https://github.com/theomessin/jetbridge/blob/develop/Client/Client.hh ) :

#pragma once

#include <Windows.h>

#include <future>
#include <map>

#include "../Protocol/Protocol.hh"

namespace jetbridge {

class Client {
 private:
  void* simconnect = 0;
  std::map<int, std::promise<Packet*>*> requests;

 public:
  Client(void* simconnect);
  void handle_received_client_data_event(void* event);
  Packet* request(char data[], int timeout = 1000);
};

}  // namespace jetbridge

As you can see, it includes future

I created a C++ CLR project, added the native c++ Client lib and created simple ClientWrapper.h / ClientWrapper.cpp files :

ClientWrapper.h

#pragma once
#include "../Client/Client.hh"
using namespace System;

namespace ClrClient {
public
ref class ClientWrapper {};
}

ClientWrapper.cpp

#include "pch.h"

#include "ClientWrapper.h"

I am not able to compile this code, because <future> is not supported when compiling with /clr or /clr:pure

I did my research and found several discussions where it was suggested to first wrap the c++ class into another c++ class that does not expose the future.

Client.hh > ClientNativeWrapper.h > ClientClrWrapper.h

I understand this suggestion but I don't understand how to proceed to "not expose" this #include <future> by including Client.hh in another c++ class, it will still be visible when compiling the c++/cli wrapper class in the end.

Pawara Siriwardhane
  • 909
  • 4
  • 11
  • 24
Guillaume
  • 9
  • 2
  • I know nothing about CLR, but it seems you want the use the PImpl idiom: https://stackoverflow.com/questions/8972588/is-the-pimpl-idiom-really-used-in-practice. – AVH Mar 17 '21 at 06:53

1 Answers1

-1

As you state it, /clr is stuck at C++17 with no current plan to move forward. <future> is C++20 (see this link)

There are two approaches that I can suggest, but one solution. A static or dynamic library used by your wrapper.

The problem is you need to hide the C++20 to the compiler compiling with /clr.

Thus PIMPL idiom + library is my suggestion.

The PIMPL part would be used in libA (a static library is probably the best option) but all of the <future> parts internal in source files.

Then a C++17 wrapper that compiles with /clr and links in the libA that contains the C++20 code. No parts of the or C++20 may then leak out of your library through header files included by the wrapper in C++17.

CJCombrink
  • 3,346
  • 18
  • 35