Problems with MSVC 2015 build

[Vort]

Hello.

I just tried to build fresh version of Bochs with Visual Studio 2015 and found several problems:

1. softfloat3e.vcxproj requires f128_sqrt.c file, which is absent. Should be removed from project file I guess;
2. #include "softfloat3e/include/softfloat.h" in fpu.cc and similar files can't be found because it is located in different directory: #include "../softfloat3e/include/softfloat.h" works fine;
3. .send_packet = send_packet, in eth_slirp.cc fails to compile because it is incompatible with C++11 standard.

First two problems can be fixed relatively easily I guess.
But problem # 3 makes me wonder: what C++ version Bochs is targeted for?
It makes sense to use C++11 since 99.9% of Bochs code is compatible with it, however other decisions are possible as well of course.

[stlintel]

I believe in year 2024 we should be fine to request C++11 minimum.
Just few months ago we saw bug reports saying C++11 constructs (like nullptr keyword) were not available for some (ancient?) build tools under MacOS. We changed the nullptr to NULL but I think we also could have said - update your compiler, we dont support before C++11 environment.

[Vort]

One more consideration: people may want to build Bochs inside of Bochs and with later standards it may become harder, since newer compilers require much more resources for compilation.
Not sure if such scenario is important, but I needed to say about it anyway.

[stlintel]

#include "softfloat3e/include/softfloat.h" in fpu.cc and similar files can't be found because it is located in different directory: #include "../softfloat3e/include/softfloat.h" works fine;

I don't want to write "../softfloat3e/include/softfloat.h", it looks ugly
For Makefile it is fixed by adding -I..
I bet there is possibility to add similar thing into MSVCPP project file.

[Vort]

Changing
<AdditionalIncludeDirectories>..;..\instrument\stubs;.\stubs;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
to
<AdditionalIncludeDirectories>..;..\cpu;..\instrument\stubs;.\stubs;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
in fpu.vcxproj allows to get rid of this problem as well, right (most likely, ..\cpu; should be added in 4 places inside of that file).

[stlintel]

Updated project files now - can you check it is okay now ?
I have no MSVCPP installed...

[Vort]

Problems 1 and 2 are solved for me, thanks.

[vruppert]

According to the output of the configure script the minimum standard is C++11. That's why I could add static_assert for structure size checking at compile time. Unfortunately the callback setup from libslirp requires the C++14 standard. Both gcc version 10 and newer and VS2019 support it. Now I had a look for a portable C++ standard version check. This is what I found (I don't know how at insert a piece of code correctly).

// C++ standard test code
#include <stdio.h>

int main(int argc, char **argv)
{
#if defined(_MSC_VER)
fpintf(stderr, "version = %ld\n", _MSVC_LANG);
#else
fprintf(stderr, "version = %ld\n", __cplusplus);
#endif
return 0;
}

I could add something like that in the slirp code to implement backward compatibility.

[Vort]

The code window looks nice, but I still don't know how to do it.

You need to put code between ```cpp and ``` and GitHub will format it accordingly.

[vruppert]

I have now added some code for C++11 compatibility. I'm currently working on a bigger update of the slirp code. Please let me know if you find issues with it.

[Vort]

Please let me know if you find issues with it.

This feature is not from C++14, but from C++20:
https://en.cppreference.com/w/cpp/language/aggregate_initialization

If I replace 201402 with 202002L, code compiles fine with MSVC 2015.
Turns out, MSVC 2015 declares C++14 compatibility, I didn't knew about it.

[vruppert]

I have now applied a change that sets the standard for the new style code to C++17. With this setting VS2019 compiles without problems. This VS version seems to support parts a of the newer standard, but reports only the official one it supports completely.

[Vort]

I still didn't understood why for C++20 feature you selected C++17 condition, but since it works fine both for VS2015 and VS2019, it is enough, at least for now. Thanks.