[CXX-1460] Compiling with c++17 and STL features using MinGW 7.2 Created: 01/Nov/17 Updated: 27/Oct/23 Resolved: 04/Dec/17 |
|
| Status: | Closed |
| Project: | C++ Driver |
| Component/s: | None |
| Affects Version/s: | 3.1.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | ads00 | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows 10 / mingw64 7.2 |
||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Description |
|
cmake command File changes to be able to compile File src\mongocxx\private\libbson.hh File src\third_party\catch\include\catch.hpp |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 04/Dec/17 ] |
|
Hi ads00 - I'm closing this ticket because I believe all of the issues you identified have been addressed, either as commits under this ticket, or other miscellaneous items that were committed in the leadup to 3.2.0-rc0. I don't happen to have a Windows/MinGW environment handy, so I haven't verified this. If you do find additional issues, please feel free to open new tickets with those issues. |
| Comment by Andrew Morrow (Inactive) [ 02/Dec/17 ] |
|
ads00 - FYI mongocxx 3.2.0-rc0 has been released which I believe should address all of the issues you identified. If possible, could you please grab it and see if it works for you in MinGW? https://github.com/mongodb/mongo-cxx-driver/releases/tag/r3.2.0-rc0 |
| Comment by Andrew Morrow (Inactive) [ 10/Nov/17 ] |
|
ads00 - FYI that work has been pushed to master, so you can just try master now if you like. |
| Comment by Andrew Morrow (Inactive) [ 10/Nov/17 ] |
|
ads00 - Could you try building with this branch and see if you can get further: https://github.com/acmorrow/mongo-cxx-driver/tree/CXX-1464 Note that the changes on that branch mean that you should no longer state -DBSONCXX_POLY_USE_STD_EXPERIMENTAL=1 on your CMake configuration line: we now note that you are doing a C++17 build and use the builtin C++17 types for std::string_view and std::optional. |
| Comment by Githook User [ 06/Nov/17 ] |
|
Author: {'name': 'Andrew Morrow', 'username': 'acmorrow', 'email': 'acm@mongodb.com'}Message: |
| Comment by Githook User [ 06/Nov/17 ] |
|
Author: {'name': 'Andrew Morrow', 'username': 'acmorrow', 'email': 'acm@mongodb.com'}Message: |
| Comment by Andrew Morrow (Inactive) [ 06/Nov/17 ] |
|
ads00 - So this is going to be a little tricky to sort out. I think part of the issue is that you just shouldn't use the std::experimental polyfills with C++17, since it offers the real deal for std::string_view and std::optional. If I set things up to use that, then clang 5 and GCC 7 agree that it is ambiguous. But when using the other polyfills (MNMLSTC, boost) the overloads aren't ambiguous, and appears to in fact be necessary. Furthermore, it looks like the official C++17 std::string_view doesn't offer a std::string_view::to_string, which we are currently relying on. I think then the solution is to add support for using the official C++17 version of std::optional, and then making the presence or absence of the overloads a compile time conditional depending on whether we are using C++17 and the std versions, or whether we are using the other polyfills. Additionally, we will need to fix all the callers of to_string. So, it is going to take a little work to dig out of this. |
| Comment by Andrew Morrow (Inactive) [ 04/Nov/17 ] |
|
OK, so, I'm not sure what is right here. Clang 4 and GCC 7 disagree. If I leave the overloads in, then clang can compile it but GCC can't. If I take the overloads out, then clang can no longer compile it but GCC can. |
| Comment by Andrew Morrow (Inactive) [ 02/Nov/17 ] |
|
Also, please feel free to send us a pull request with the addition of the <functional> header. |
| Comment by Andrew Morrow (Inactive) [ 02/Nov/17 ] |
|
I think that ambiguity is deeply subtle. Something to do with the explicitness of the std::optional constructors in C++17. Note that the explicit-ness of the constructors appears to be SFINAE'd or similar: http://en.cppreference.com/w/cpp/utility/optional/optional |
| Comment by ads00 [ 01/Nov/17 ] |
|
Yes, call is ambiguous. std::optional<A> can be constructed passing an instance of A so i removed the overload with (bsoncxx::document::view_or_value doc) I will test catch on master when i'll have some time |
| Comment by Andrew Morrow (Inactive) [ 01/Nov/17 ] |
|