[CXX-1636] Conflict with <windows.h>. Different include order lead to different result. Created: 09/Aug/18  Updated: 07/Feb/24

Status: Backlog
Project: C++ Driver
Component/s: Documentation
Affects Version/s: 3.3.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: drink Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Bug, neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: windows 10
compiler: visual studio 2017


Attachments: Text File CMakeLists.txt     Text File buildOutput.txt     Text File main.cpp    
Epic Link: Reference Docs Improvements

 Description   

 

#include <mongocxx/client.hpp>
#include <windows.h>
int main() {
    return 0;
}


 This can complie success.

#include <windows.h>
#include <mongocxx/client.hpp>
int main() {
    return 0;
}

This cause strange error.
Error (active) E0145 member "bsoncxx::v_noabi::types::b_double::type_id" may not be initialized.



 Comments   
Comment by A. Jesse Jiryu Davis [ 30/Aug/18 ]

Warn users to define NOMINMAX when compiling with MSVC, then close.

(Consider an extra pragma warning during the build, too.)

Comment by drink [ 15/Aug/18 ]

Thx very much.

"Defining NOMINMAX is standard practice in modern Windows C++ projects."

I have learned it now.

Comment by Andrew Morrow (Inactive) [ 14/Aug/18 ]

Some things to note here:

  • You should always include the windows headers first, before including basically any other headers (C++ standard library, MongoDB drivers, boost, etc.).
  • You can work around this particular collision by adding #define NOMINMAX before including the Windows headers.
  • The C++ driver could potentially do that itself in the prelude/postlude headers, but I don't see much advantage to doing so. Defining NOMINMAX is standard practice in modern Windows C++ projects, and I don't want to pollute our headers with papering over other systems legacy issues.
Comment by A. Jesse Jiryu Davis [ 14/Aug/18 ]

Possibly with push_macro: https://stackoverflow.com/questions/1543736/how-do-i-temporarily-disable-a-macro-expansion-in-c-c

Comment by A. Jesse Jiryu Davis [ 14/Aug/18 ]

Looks like the error in options/find.hpp:216 is the root cause: windows.h defines “max” as a macro, and find.hpp tries to declare “max” as a member function. After macro substitution find.hpp cannot compile. I don’t know if there’s a way to change find.hpp so that it compiles if it’s included after windows.h.

Comment by drink [ 14/Aug/18 ]

I am using Visual Studio 2017.

I tried the "__STDC_LIMIT_MACROS" preprocessor definition, it didnot work.

I have attach the output.

Comment by A. Jesse Jiryu Davis [ 10/Aug/18 ]

That is odd. I only have a Visual Studio 2015 environment handy, and I can't reproduce the error there. Could you attach the full output from the Visual Studio "output" tab here so we can see all the messages?

What happens if you open the project properties, go to "C/C++" "Preprocessor" "Preprocessor definitions", and add the preprocessor definition __STDC_LIMIT_MACROS ?

Generated at Wed Feb 07 22:03:24 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.