Header ordering conflicts with Boost libraries

[cmazakas]

I'm using a combination of Boost and the cpprestsdk but unfortunately, because of the definition of U, the user will get cryptic parser failures in the Boost implementation of type_traits. To remedy this, I have to include all of my Boost dependencies before any cpprestsdk header files. There's also a macro one can define to make header ordering irrelevant: #define _TURN_OFF_PLATFORM_STRING

See: microsoft/vcpkg#836

[ksinica]

I've run into the same issue today:
boost/move/detail/type_traits.hpp(757): error C2187: syntax error: ')' was unexpected here

U is a very popular name for a template parameter, and this unfortunate definition may result in ill-formed code (taken directly from boost/move/detail/type_traits.hpp):

template <class U>
static yes_type test(U&, decltype(U(source<U>()))* = 0);

[chri7325]

We have also had to make the same fix in our codebase while moving to VS2017.

[HumamHelfawi]

Any intention to fix this soon? Any news?

[garethsb]

Ability to use _TURN_OFF_PLATFORM_STRING successfully should be resolved by #693 on master at Feb 7. Hopefully will be in a v2.10.3 soon.

[svebert]

Hi,
I just stumbled over this issue. I installed cpprest via vcpkg on Windows. In that specific version (cpprest_2_10) this problem ist not fixed. I am not sure, whether only the cpprest release in vcpkg is too old (I installed it on 1.1.2019) or if it is still not fixed in the master.

[KindDragon]

Please remove macros U from cpprestsdk

[milanchandna]

Ran into the same issue.

I was using auto-generated client stubs from Swagger which internally uses boost and cpprest.
This issue is forcing me to change auto-generated code which I was trying to avoid.
Either I have to use #undef U or include all boost dependencies before cpprest.

Please fix it.

[garethsb]

@svebert @milanchandna - as pointed out previously, this should be resolvable for every release since v2.10.3 (Aug 2, 2018) by defining the _TURN_OFF_PLATFORM_STRING in your project.

[milanchandna]

@garethsb-sony completely missed that workaround. Thanks for pointing it out.