All very well, but I'd be really happy once (if) we ever get proper C99 support in MSVC. We basically need that at the neovim project if we want our code to compile with MSVC. We don't want to compromise either, by for example compiling as C++ and not using some C99 features (we do use compound literals, we don't cast from void pointers, et cetera). The CRT improvements in MSVC 2013 and 2014 are a step, but only a small one. Sadly, compiling as C forces some kind of old mode where we can't even use declare-anywhere. For now, it seems like we'll need to let MingW and its offspring do it. Does anyone have a workaround?
This tool has been unnecessary since VS2013. I posted some background info and links about it and MS' apparent attitude reversal back in Nov: https://news.ycombinator.com/item?id=6728226
Is there any problem with MinGW ?
From my very limited experience gcc is just a better compiler than MSVC: it generates faster code, has more options to configure it (more optimization options, more options for displaying warnings, all the new floating point stuff available, actually supports new standards and let you choose which language version you want etc.).
No, I like both gcc and clang, and thus mingw. Still, we would like to be portable to as many modern, often-used compilers as we can.
Also anecdotally, I wrote a software renderer a few months ago that ran almost 50% faster when compiled with MSVC 2013 than with MingW 64 (gcc 4.8), all optimizations enabled. This might not be true for other types of programs though.
GCC certainly releases more often than Visual Studio, with the end result being that GCC has support for newer standards much sooner than Visual Studio. But if you intend to run your programs on Windows systems without GCC installed, you have to find the support DLL, and it's not always easy to find.
Not sure if that is true in general - the few proper benchmarks I found indicate that there is no clear winner. (Except for the Intel compiler, which beats both)
Right. I am speaking from experience with relatively simple number crunching code. It became faster once I upgraded to newer version of gcc.
Now even very simple things (like say 8 queens) are just 5-10% faster when compiling with GCC 4.8 comparing to MSVC.
* creates binaries that link to the platform CRT (no need for any redistributable) as long as you keep within C99 or C11
Cons:
* not officially supported yet
* doesn't yet support enough C++ to be useful for anybody wanting that
* while the C99/C11 language is available, you still need to rely on the Windows header files and libraries, so you have variable length arrays, declare anywhere, compound initializers, _Generic, but not snprintf, fenv.h, etc.
clang-cl and MS C++ ABI compatibility for Clang/LLVM is going to be very exciting. Some said it was an impossible project but it is quickly progressing. The start of SEH is already committed. I believe the mangling is complete. Linkage types are still being tweaked. Windows Phone is already partially supported. The inalloca attribute has been in ToT for a long time. I think it will be in a usable state within a year.
Sometimes you just have to use a binary library that you cannot recompile. If it is C++, you are limited with your compiler choices due to ABIs.
According to the article, C99 support was one of the motivations for doing this.
"As part of this work, we've completely rewritten the core implementations of the printf and scanf functions (now with no #ifdefs!). This has enabled us to implement the remaining C99 features for the stdio library, to improve correctness checks in the library, and to fix many conformance bugs and quirks"
If GCC (MinGW) is working for you then why do you, a FLOSS developer, want your code to be compiled using the proprietary MS compiler? I'm genuinely interested.
It's often better to integrate with the native tools of a given platform. For example, I wouldn't really ever contribute to a Mono project, even if it's on Linux, because .NET is weird Windows stuff. Same thing in reverse with MinGW and Windows.
And if you want your project to truly treat Windows as first class, you have to recruit people who know, love, and use Windows.
Windows has a number of native compilers: MSVC, MinGW GCC, Clang, icc, Pelles C, Embarcadero C++Builder etc. Nothing makes MSVC special, except that it happens to be from the same vendor as the operating system. MinGW GCC is free software, has better standards support, better warning output and can compile more FOSS libraries. These are all pretty desirable features, especially if you're a FOSS developer.
I consider myself a Windows user and developer, but I have no love for MSVC. I'd much rather have everything I use compile under MinGW GCC.
You're the first person I've ever heard who considers MinGW GCC 'native.' Every time I've worked on an OSS project that uses MinGW, every Windows dev who comes along says "ugh, MSVC++ please."
Why is .NET "weird Windows stuff"? Apart from obviously Windows-specific libraries like WMI, WinForms, etc. Even Microsoft released an example of the CLI that'd compile for FreeBSD among other OSes. So the cross-platform part of the runtime and much of the basic libraries is truly built-in.
To give you a short and blunt example - if your API is C++ then you can't mix gcc/msvc dlls - simply because exported symbols won't be found, and much more other (hidden) problems.
Never going to happen. For Microsoft C's time is passé.
Herb Sutter already stated this multiple times.
He was very clear that C99 support was only was is required by the C++ standard and to allow specific well known open source projects, which he referred to, to be ported to Windows.
So it's "only" required by their primary language standard, as well as used in some very popular software...
If that's barely enough to move Sutter into action, I wonder what would be an actually compelling case to him. The heavens open and a booming voice commands him to implement features X, Y and Z?
I read somewhere that Microsoft settled on C89 for the Windows kernel etc. so as far as their primary language goes their compiler implements it just fine.
VS 2013+ does support compound literals and mixed declarations and usage. The latter is oddly buggy, but it's a rare area where they're fairly responsive to bug reports.
From the blog post:
>We have eliminated most of the manual resource management in the code through the introduction of several special-purpose smart pointer and handle types. Enormous functions have been split into smaller, maintainable pieces. We have eliminated 75%(2) of the conditional compilation preprocessor directives (#ifdef, #else, etc.) by converting internal implementation details to use C++ features like templates and overloading.
FYI... The author of the blog post (James McNellis) also has an excellent video presentation that explains that paragraph in more detail.
I kind of joked here: https://news.ycombinator.com/item?id=7843301 - but now I can't really wait for it. This is huge! This means that once major products pick up and develop their creative tools (Maya, MotionBuilder, Photoshop, etc.) - plugin developers no longer have to ship for multitude of CRT versions.
Also finally things like Python, Perl, etc. can stick on one runtime and not care for a very long time.
Great stuff Microsoft! I really really can't wait for it. I don't care even if no new C++ features are implemented - only this is that important.
Nice to see them talking about C99, even after they said the focus is only C++... when for everybody else, the horizon is C11. Guess it's something along the lines of "let's handicap a bit all open-source projects that want to support Windows by forcing them to use an older language version that also has platform specific gotchas, maybe even rewrite the runtime to add more platform specific goodness"...
I was expecting them to figure out symbol versioning (eg how glibc deals with the similar problem). It isn't clear if they have done that, or instead are hoping to always have backwards/forwards compatible code and data structures.
"We have converted most of the CRT sources to compile as C++, enabling us to replace many ugly C idioms with simpler and more advanced C++ constructs. "
Of course they wouldn't have to do that if they had a functioning C compiler.
But snark aside, this is going to help GCC and CLang which will be able to target the stable runtimes. It doesn't matter than VCRuntime will continue to be versioned since each compiler will provide its own startup and EH (they already do). In fact, I wonder if this is a move to begin officially supporting alternate compilers. Is VCExpress going to be replaced with a LLVM-based package?
Will it be possible to create a shim msvcrt.dll that forwards to the new libraries? Then old programs can finally take advantage of bug fixes.
I doubt that GCC (MinGW) will be able to use this. What a pitty.
MinGW relies on the CRT that ships with every Windows since Win95 (and Visual Studio 6).
Microsoft could fix this situation by merging the CRT that ships with Windows (the original one) and Visual Studio (the forked of version madness) together. A simple Windows update for Windows NT 5.x+ would be great (of course it should be backward compatible).
"Before this refactoring, the sprintf functions, which write formatted data to a character buffer, were implemented by wrapping the result buffer in a temporary FILE object and then deferring to the equivalent fprintf function."
