|
I'm guilty of glossing over most of that link. My fault. Serves me right for digging it up while in the middle of other things..
I admit a lot of my distaste for MSVC is historical. Pre 2017 it wasn't great, but since then I haven't used it as much as I used to because I do cross compiling mostly these days for MCUs and such.
That it didn't support SFINAE was just unacceptable, IMO.
At the end of the day, I don't trust their compiler products, and frankly, they earned that. It will take some time - a consistent showing of compliance over several standards versions for me to want to rely on them again.
Real programmers use butterflies
|
|
|
|
|
Text like a command line is also "visual"
|
|
|
|
|
I never claimed otherwise.
|
|
|
|
|
It's possible to do portable executables (assuming I've picked the context right) with GCC , but clunky (haven't tried to do it with clang). You have to use windres to build a .res file, then you can link that as a source file like any other .c or .cpp file. Looking at an old makefile I think the "-mconsole" and "-mwindows" flags on the GCC command are important, but it's been long enough since I touched this that I can't really remember exactly how it works.
|
|
|
|
|
Thanks for the heads up
Real programmers use butterflies
|
|
|
|
|
|
|
Another clang compiler for Windows is incorporated into RAD Studio by Embarcadero Technologies (bcc32c and bcc64). There is a Community version of the IDE which is free for one year.
|
|
|
|
|
clang and gcc can compile PE files just fine. The only thing is that debug information is in DWARF format, not PDB, but that just means you use GDB rather than a Microsoft debugger.
The company I work for has used GCC to produce Windows executables from Ada, C and Fortran for decades (20 years counts as 'decades', right?). The gcc linker can be slow in some circumstances, but aside from that, it works just fine.
What frustrates you with msvc, BTW? It's improved immensely since the dark days of the late 90s/early 2000s, when it felt like they'd never keep up with the C++ Standard...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: What frustrates you with msvc, BTW?
Well, trying to use it to do SFINAE it failed, and worse, because it didn't support it, it also didn't support std::enable-if.
Now I don't know if they do now. *googles* - looks like they do finally, but frankly, I don't want to have to guess about which parts of the elephanting standard they feel are important while I'm coding. Or wonder if the code I'm writing is problematic or if it's the compiler being well... MSVC. It's a time sink.
And I hate their language extensions. everything is a #$&# pragma
Real programmers use butterflies
|
|
|
|
|
C++17 support seems pretty complete in MSVC2017 and 2019 - I generally use this set of tables on CppReference to work out what is/isn't supported by any particular compiler.
I'm using gcc-8 & msvc2017 for my current project, and it's gcc that frustrates me slightly, as it can't support this library...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Yeah but look at their C++20 support compared to GCC.
Someone should remind MS it's 2021.
I don't want to have to find out they don't support something the hard way when I'm in the middle of coding.
I'm not using C++20 at the moment, but I plan on switching over soon. If MS has been consistent about anything, it's being years behind the standards.
So I stand by the title of the post
Also if a codebase won't work with GCC I'd argue the problem is almost certainly with the codebase, not gcc.
Because
1. GCC is a modern, popular compiler that is very standards compliant compared to other offerings. If your source can't work with it you're shooting yourself in the foot
2. What about your code isn't actually C++, but really a variant of C++ involving vendor specific extensions? It's not always the issue, but I find it usually is.
Real programmers use butterflies
|
|
|
|
|
And you really want to fight the new compiler bugs? It is only the second bugfix for VS 2017 that does not contain a C++ compiler fix - I guess they gave up, not finished.
|
|
|
|
|
I don't typically use MSVC. In fact, I don't even test my code to see if it compiles on MSVC anymore - just clang and gcc. If MSVC can't compile it, MSVC is broken, as far as I'm concerned. That's how I treat it.
Real programmers use butterflies
|
|
|
|
|
|
I think you misunderstand me. All compilers have bugs. The question is whether standards compliant code will compile with them or not.
Sure, gcc has some bugs, and some of those bugs might impact the above, but they have a lot of catching up to do if they want to ride the Microsoft fail train. This was especially true on previous versions of MSVC, but even today they're still lagging behind clang and GCC in terms of C++ standards support.
At the end of the day, that's what I care about.
Like, as an analogy (but i don't do webdev) I don't care that Chrome may have a rendering bug. I care that it supports HTML5, so that my HTML5 code will theoretically render capably under that system. If there's a specific bug I can deal with that, but that's knowing that Google knows it's a bug and is treating it like a bug.
Consider the different approach MS took with IE. It mirrors their treatment of C++ in terms of standards.
Microsoft's lack of standards compliance isn't treated as a bug. At least historically (which I can speak to with confidence, as opposed to their specific culture and attitude *today* WRT to C++) has been that it's by design, and if you code in the Microsoft ecosystem, you just have to suck it up. Maybe they'll get around to it on the next major version, maybe not.
That's a rather marked difference in terms of what I can expect and what I can rely on when I go to design my code.
In the first case, worst case I have a conditional for Chrome, to work around the bug, and make a note of it in the source.
In the second case, I basically have to fork, because not only is it not going to be fixed, but it's probably not the only thing they *decided* to do differently.
Real programmers use butterflies
|
|
|
|
|
You can run MSVC++ in C++17 mode, unlike IE which only got standards mode in betas, but not in releases.
|
|
|
|
|
Fair enough. But C++20 support is still flaky
Real programmers use butterflies
|
|
|
|
|
Indeed. C++20-support in MSVC++ is labeled experimental. As it is for Clang and GCC. Ok, Clang calls it's status "partial", but that doesn't read any better than "experimental".
|
|
|
|
|
From CPPreference.com's compiler support page (i don't have the link handy, sorry), GCC's C++20 support looks pretty good.
Are you looking at v10 or are you considering an earlier version?
Real programmers use butterflies
|
|
|
|
|
[C++ Standards Support in GCC- GNU Project - Free Software Foundation (FSF)](https://gcc.gnu.org/projects/cxx-status.html#cxx20)
|
|
|
|
|
|
Mike Hankey wrote: simulators
In the late 80's I worked as a software consultant at Wright Patterson Air Force Base. One of my projects was doing the cockpit heads-up display for an F-16 simulator. The "window scenery" was based upon a camera that flew along a scale model of terrain that was around 25 feet tall and over 200 feet long. The best part was the cockpit itself. It was mounted on a huge gimbaled arm that could pitch, yaw, and roll to match the pilot's control inputs.
Unfortunately I never got to fly the simulator. This was probably a good thing, as I would have almost certainly tossed my cookies after a barrel roll or two.
Software Zen: delete this;
|
|
|
|
|
I've seen those simulators, not in person and thought how cool they were. Bet they've come a long way since you worked on them?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
