Installing Visual Studio 2017

[Chris]

Make that "cross platform support" in the sense that "we do not want to write cross-platform code but still support all platforms."
In other words: It is often used as a crutch to make code work that isn't really portable.

I can write perfectly portable C code, but MSVC will refuse to compile it because it thinks C hasn't been updated in over 20 years. It gets some new functions as a result of C++ inheriting them, but anything from C99 or C11 that needs actual syntax/parser changes is out -- no restrict or inline support, no _Bool, _Atomic, _Alignas, _Static_assert, _Generic, etc. I remember reading a blog post where the MSVC dev team recommends using MinGW for modern C support.

I was interested in that Clang frontend for MSVC project, which would've also worked to support modern C code in the MSVC toolchain, but last I heard Microsoft cancelled/stopped working on it.

[ibm5155]

this thread made me to think, are there any proper debug with ide when compiling software on linux?
Heck, even borland C++ from ms-dos era supports that...

Still the features that I love in visual studio is being able to edit the vars data and even code while debugging, but I could live without it...

Since you guys also do linux code, what ide do you guys use? (dont tell me it's vi D:)

[Graf Zahl]

AFAIK the best you can get is some GUI wrapper around gdb. Even Apple does not offer more in XCode and the result is very inferior to MSVC's fully integrated debugger most of the time.

The main "problem" with Linux is that too many of the decision makers are too hard core and not using the command line is for wimps, according to them. I had my "fun" with some of these people at work over the years.

[Rachael]

Indeed, a lot of these hard-core command-line advocates is what has hurt Linux immensely over the years. In most cases, elitism is bad, in all of its forms, and this is the result of that.

[Chris]

AFAIK the best you can get is some GUI wrapper around gdb.

GDB is very adept at debugging, so it makes sense that a debugging GUI would wrap around it. That doesn't necessarily mean that it it's just dressing around a CLI, though. I use the KDevelop IDE, for example, which has built-in graphical debugging; there's a tab to directly interface with gdb, but there's also tabs specifically to show/deal with the frame stacks, breakpoints, and disassembly/registers, along with keyboard shortcuts and menu options to launch and control execution of configured executables (which interacts with the editing window as you'd expect). There's probably more it can do that I've not really looked into.

[drfrag]

I use Code::Blocks on windows and it's also available on linux, people also recommend CodeLite. There are other IDEs.

https://stackoverflow.com/questions/241 ... -for-linux

[drfrag]

I've updated the first post with an alternative layout adding the v140 toolset (VS 2015) and XP support. Note that you only require one of the toolsets v141 or v140.

I've fixed ZDoom32 compilation with VS 2017, there are worrying problems with the v141 toolset and old versions. First i had to revert "Use lambdas for more concise code" or internal compiler error and then was a SAFESEH linker error with asm files. Last but not least there is a crash in the old GL renderer (1.9.1b) in vanilla maps, it's not there with the VS 2015 toolset nor with MinGW. It's in 'static int MergeMapSections(int num)' in gl_setup.cpp, vsection can get crazy values outside array bounds. I've added a workaround. You know I.R. very clever (i mean i tracked the vsection value but a real fix is way beyond the skills of poor I.R. , i don't even know if there's a problem with the code or it's just a VS thing). The game works well so that mergecount must not be very important.
https://github.com/drfrag666/gzdoom/com ... 8d059e2cad

Now, why am i commenting this? This could be a problem when bisecting to track old bugs but mainly may be it would be a good idea to stick to the v140 toolset for now with the strange problems in the recent devbuilds just in case. Or may be i'm just imagining things and the v141 toolset is fine.