1

I am trying to use Casablanca, http server. to do so, I need to include headers files from Casablanca, which contains few macro and typedef that cause issues in my project.

so my file look like this.

simplehttpserver.h 

#include "cpprest/json.h"
#include "cpprest/http_listener.h"
#include "cpprest/uri.h"
#include "cpprest/asyncrt_utils.h"


SimpleHttpServer {

SimpleHttpServer(utility::string_t, std::function<void(http_request)> &request_handler); 

void OnInitialize();

void StartServer();
void StopServer();

private: 
 std::unique_ptr<http_listener> m_listenerUptr;
 // Handlers
 std::function<void(http::http_request)> m_all_requests;

 pplx::task<void> open() { return m_listenerUptr->open(); }
 pplx::task<void> close() { return m_listenerUptr->close(); }


 // SimpleHttpServer http_server_;
 utility::string_t address_;  

}

Say in my original code where I want to include this.

#include "simplehttpserver.h"

this causes all Casablanca header files pre-compiled into my project which conflicts with macros and typedef in my project. e.g. __declspec

I don't want to change my macros cause that will be lot of code change. and I don't want to change Casablanca header files, cause that will also cause long term maintenance overhead.

I am sure, this must be very common problem in c++, can someone please help me how can resolve this.

thanks in advance.

Abhay
  • 564
  • 6
  • 14
  • 2
    namespaces were invented to solve exactly this problem. If casablanca pollutes global namespace is rubbish, you just have to use different lib. – SergeyA Jan 06 '16 at 22:23
  • 2
    Also, a library that did use macros should be using names that would be near impossible to clash with any other name. For example `CASABLANCA_MIN_VALUE` instead of just `MIN`. Also `__declspec` is defined by Microsoft header, isn't it? – PaulMcKenzie Jan 06 '16 at 22:25
  • 3
    Neither your code nor a third-party library should `#define __declspec`. It's a reserved identifier. – 5gon12eder Jan 06 '16 at 22:27
  • 1
    Using C++ you have plenty of options to avoid macros in the first place – Ed Heal Jan 06 '16 at 22:55
  • 1
    Personally, I think it is both the fault of the library to use "easy to duplicate" macro names, and your personal macros using "easy to duplicate" names. That never works out well. – PaulMcKenzie Jan 06 '16 at 23:10
  • I agree with all the comments, but is there a way to solve this problem, can some one provide a sample or some pointer I can use ? :( – Abhay Jan 06 '16 at 23:22
  • There is no simple general solution that will magically make your errors go away. You'll have to fix your macro names (shouldn't be all that difficult with a decent editor) or avoid using that library. You might be able to mitigate the problem to some extent by reducing the number of `#include`s. If you only need a tiny piece of the third-party library, you might be able to wrap it into your own abstraction and compile that as a separate translation unit with as few of your own headers `#include`d as possible. – 5gon12eder Jan 06 '16 at 23:43
  • What macros are specifically the problem? What platform are you building for? You can generally solve these issues by #undef'ing the problematic macros before they interfere with other headers. – roschuma Mar 03 '16 at 02:12

0 Answers0