Fixing the Windows/MinGW builds

[martinwhitaker]

The latest release of mingw64 has caused our CI to fail on the Windows/MinGW tests. The problem is that rpcndr.h (which is indirectly included by windows.h) defines a type named "byte" which collides with a definition in cpp_type_traits.h (included indirectly by the STL). This is only a problem because many of our header files contain "using namespace std" which exposes the STL definition.

I first tried to fix this by reordering the header file inclusion, but soon found the problem was more pervasive than I first thought.

I have fixed it locally by removing "using namespace std" from all header files and, where necessary , adding the "std::" prefix in the header files and adding a "using namespace std" in the source files. This results in a lot of code churn, but does the job.

However, in a few header files I find

#ifdef HAVE_IOSFWD
# include  <iosfwd>
#else
class ostream;
#endif

On the systems I'm testing on, HAVE_IOSFWD is true, and all is well. If I try forcing HAVE_IOSFWD to false, the compile fails with

./source/verinum.h:28:7: note:                 ‘class ostream’
...
../source/design_dump.cc:60:1: error: reference to ‘ostream’ is ambiguous
...
/usr/include/c++/10/iosfwd:141:33: note: candidates are: ‘typedef class std::basic_ostream<char> std::ostream’

However, when I add the "std::" prefix to the forward declaration of ostream, the compile fails with

../source/verinum.h:28:12: error: using typedef-name ‘std::ostream’ after ‘class’
   28 | class std::ostream;
  ...
/usr/include/c++/10/iosfwd:141:33: note: ‘std::ostream’ has a previous declaration here
  141 |   typedef basic_ostream<char>   ostream;

I don't know if this would also occur on systems that don't have iosfwd.h, and if so, how to properly fix it. Any suggestions?

[steveicarus]

I think no header files should ever have any "using namespace X" in them, so it is correct that those should be taken out. Then, on systems that don't HAVE_IOSFWD, I think the right answer is to include <iostream>.

…

On Thu, Nov 4, 2021 at 7:58 AM martinwhitaker ***@***.***> wrote: The latest release of mingw64 has caused our CI to fail on the Windows/MinGW tests. The problem is that rpcndr.h (which is indirectly included by windows.h) defines a type named "byte" which collides with a definition in cpp_type_traits.h (included indirectly by the STL). This is only a problem because many of our header files contain "using namespace std" which exposes the STL definition. I first tried to fix this by reordering the header file inclusion, but soon found the problem was more pervasive than I first thought. I have fixed it locally by removing "using namespace std" from all header files and, where necessary , adding the "std::" prefix in the header files and adding a "using namespace std" in the source files. This results in a lot of code churn, but does the job. However, in a few header files I find #ifdef HAVE_IOSFWD # include <iosfwd> #else class ostream; #endif On the systems I'm testing on, HAVE_IOSFWD is true, and all is well. If I try forcing HAVE_IOSFWD to false, the compile fails with ./source/verinum.h:28:7: note: ‘class ostream’ ... ../source/design_dump.cc:60:1: error: reference to ‘ostream’ is ambiguous ... /usr/include/c++/10/iosfwd:141:33: note: candidates are: ‘typedef class std::basic_ostream<char> std::ostream’ However, when I add the "std::" prefix to the forward declaration of ostream, the compile fails with ../source/verinum.h:28:12: error: using typedef-name ‘std::ostream’ after ‘class’ 28 | class std::ostream; ... /usr/include/c++/10/iosfwd:141:33: note: ‘std::ostream’ has a previous declaration here 141 | typedef basic_ostream<char> ostream; I don't know if this would also occur on systems that don't have iosfwd.h, and if so, how to properly fix it. Any suggestions? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

-- Steve Williams ***@***.***

[martinwhitaker]

Thanks Steve, I'll do that.

[caryr]

This seems to be complete so closing.