Mingw-w64 is an advancement of the original mingw.org project, created to support the GCC compiler on Windows systems. It has forked it in 2007 in order to provide support for 64 bits and new APIs. It has since then gained widespread use and distribution.
The development and community are very active and welcoming with new contributors every month and simple installers.
initial Release: 2016-10-19
You can also look at the full list of versions.
Mingw-w64 interacts a lot with other projects in order to help everyone move forward. Contributions have been going to and coming from these projects:
no, this was not the case. the bracket checker is best implemented with a stack. I am not asking for help, just a compiler fix. that line was all that was wrong. it was 4000+-line complicated code. I ran it through my brace-checker.
Oh, I know a patch would be welcome I put this in here so that it's actually known and tracked lol... I've narrowed it down to the fact that unless something from the libstdc++ header directory is included, nothing will unconditionally define __USE_MINGW_ANSI_STDIO as the one that is made in bits/os_defines.h via bits/c++config.h. Until and unless a C++ include is made __USE_MINGW_ANSI_STDIO is made based on the decision in _mingw.h. The only time __cplusplus has any effect in that decision in the...
gcc version 7.1.0 (i686-win32-sjlj-rev1, Built by MinGW-W64 project) so the v5 runtime I guess? (is there a way to find out the runtime release version out of curiosity???) yes, v5.x branch patches are welcom ;)
gcc version 7.1.0 (i686-win32-sjlj-rev1, Built by MinGW-W64 project) so the v5 runtime I guess? (is there a way to find out the runtime release version out of curiosity???) yes, v5.x branch
I have to say...in my 25 years in this industry, this truely has to be one of the most useless "bug reports" I have ever seen. For all I know, this is floating point precision error, automatic casting conversion issues, or god knows what. Until and unless you can provide a test case that is repeatable and demonstrates the issue, this should be closed/invalid.
Include order affects selection of printf and __mingw_printf
it's a bug you can't nail down to a unit test, but in a complex program it will pop up and rear its ugly head. I got it in my test results of commercial code.
iostream clog exponent sign not always correct
well I take that back on the default printf function...caveat being that using the C++ driver should get you the mingw ansi printf function by default. I did find a combination of headers that negates it for some reason, and that is if math.h is included AFTER stdio.h.
Finally, for the c++ version, look into the iomanip, specifically std::setprecision, std::setw, and std::setfill manipulators.