Microsoft Visual C++ is the Internet Explorer of C++ compilers.
-
What else is there to add? Honestly, how adept is the LLVM stuff at creating Windows PE binaries? Because I don't even want to deal with anything other than clang or gcc anymore.
Real programmers use butterflies
-
What else is there to add? Honestly, how adept is the LLVM stuff at creating Windows PE binaries? Because I don't even want to deal with anything other than clang or gcc anymore.
Real programmers use butterflies
-
What else is there to add? Honestly, how adept is the LLVM stuff at creating Windows PE binaries? Because I don't even want to deal with anything other than clang or gcc anymore.
Real programmers use butterflies
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.
-
Well, Visual C++ is not a compiler, it's an IDE. If you want to use the compiler standalone it is quite easy, I do it most days in a command prompt window using VSCode.
Visual studio is an IDE MSVC is a compiler. MSVC Compiler Options | Microsoft Docs[^] If there's a way to launch it in "IDE mode" I'm not aware of it, and I worked on Microsoft's IDE team.
Real programmers use butterflies
-
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
-
Visual studio is an IDE MSVC is a compiler. MSVC Compiler Options | Microsoft Docs[^] If there's a way to launch it in "IDE mode" I'm not aware of it, and I worked on Microsoft's IDE team.
Real programmers use butterflies
To be fair it's not that much of an exaggeration to say that half of Microsoft's developer products have start with the word 'Visual'. If they'd developed Skype internally they'd probably have called it Visual Phone Calls.
-
Visual studio is an IDE MSVC is a compiler. MSVC Compiler Options | Microsoft Docs[^] If there's a way to launch it in "IDE mode" I'm not aware of it, and I worked on Microsoft's IDE team.
Real programmers use butterflies
-
Quote:
cl.exe is a tool that controls the Microsoft C++ (MSVC) C and C++ compilers
And cl is the command I use for compiling in VSCode; nothing visual about it (except when my simple mistakes get spat out. :(( ).
Notice how it says *it controls* the Microsoft C++ (MSVC) C and C++ compilers. cl.exe is a command line control tool. It is not the compiler. Microsoft names everything development oriented with Visual, as Dar said. It doesn't mean it's literally visual. I blame microsoft's marketers.
Real programmers use butterflies
-
To be fair it's not that much of an exaggeration to say that half of Microsoft's developer products have start with the word 'Visual'. If they'd developed Skype internally they'd probably have called it Visual Phone Calls.
Yeah, it's frustrating.
Real programmers use butterflies
-
Notice how it says *it controls* the Microsoft C++ (MSVC) C and C++ compilers. cl.exe is a command line control tool. It is not the compiler. Microsoft names everything development oriented with Visual, as Dar said. It doesn't mean it's literally visual. I blame microsoft's marketers.
Real programmers use butterflies
honey the codewitch wrote:
cl.exe is a command line control tool. It is not the compiler.
c:\program files (x86)\microsoft visual studio 14.0\vc\bin>cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86
Copyright (C) Microsoft Corporation. All rights reserved.usage: cl [ option... ] filename... [ /link linkoption... ]
-
honey the codewitch wrote:
cl.exe is a command line control tool. It is not the compiler.
c:\program files (x86)\microsoft visual studio 14.0\vc\bin>cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86
Copyright (C) Microsoft Corporation. All rights reserved.usage: cl [ option... ] filename... [ /link linkoption... ]
Of course the thing that controls the other thing will dump output from the other thing when you run it. I refer you again to the documentation I linked to, which clearly states that the cl.exe is a utility that controls MSVC. Even if it's currently embedded in cl.exe the concept is distinct, meaning microsoft may expose the *MSVC* compiler as a service at some point (if they haven't already, i haven't kept up with their latest nonsense)
cl.exe is a tool that controls the Microsoft C++ (MSVC) C and C++ compilers and linker. cl.exe can be run only on operating systems that support Microsoft Visual Studio for Windows.
Read it carefully, and I think you'll understand why I call the compiler Microsoft Visual C++ and not "cl.exe"
Real programmers use butterflies
-
Of course the thing that controls the other thing will dump output from the other thing when you run it. I refer you again to the documentation I linked to, which clearly states that the cl.exe is a utility that controls MSVC. Even if it's currently embedded in cl.exe the concept is distinct, meaning microsoft may expose the *MSVC* compiler as a service at some point (if they haven't already, i haven't kept up with their latest nonsense)
cl.exe is a tool that controls the Microsoft C++ (MSVC) C and C++ compilers and linker. cl.exe can be run only on operating systems that support Microsoft Visual Studio for Windows.
Read it carefully, and I think you'll understand why I call the compiler Microsoft Visual C++ and not "cl.exe"
Real programmers use butterflies
This can be investigated with something like Project Explorer, by compiling some crazy "template template template parameters" stuff, which may give insane compilation time. Just reading the documentation, I can only guess that cl.exe is compiler, which runs the linker if necessary:
CL automatically invokes the linker after compiling unless the /c option is used.
From our point of view, this is not important, unless we want to develop some new makefile system. Not in my schedule for this week, anyway...
-
This can be investigated with something like Project Explorer, by compiling some crazy "template template template parameters" stuff, which may give insane compilation time. Just reading the documentation, I can only guess that cl.exe is compiler, which runs the linker if necessary:
CL automatically invokes the linker after compiling unless the /c option is used.
From our point of view, this is not important, unless we want to develop some new makefile system. Not in my schedule for this week, anyway...
Fair enough, but based on the documentation produced by microsoft, and all of its related materials they do indeed call their compiler MSVC. Therefore, I don't think it's exactly accurate to correct someone for referring to it as Microsoft Visual C++. MSVC isn't an IDE. Visual Studio is an IDE, so there isn't really cross-confusion here save for the word "Visual" which is a misnomer when it comes to MSVC, but has *always been the same misnomer* ever since they introduced it, regardless of IDE. It's just what they call it. Now, we may have different ideas about what it's "really" called. I tend to lean toward what the people that created it call it in their actual documentation and other materials. You may call it what the command line executable is named. I honestly don't care. I just don't think what I called it bears correcting, since it's accurate. It ultimately comes down to which name you think is more important (the cli name, or MS's given name), and I think reasonable people can disagree about that while both being correct in what they call it. Now, if you take issue with that, so be it. I'm willing to die on that hill. :laugh:
Real programmers use butterflies
-
What else is there to add? Honestly, how adept is the LLVM stuff at creating Windows PE binaries? Because I don't even want to deal with anything other than clang or gcc anymore.
Real programmers use butterflies
honey the codewitch wrote:
Honestly, how adept is the LLVM stuff at creating Windows PE binaries?
This free ide for windows uses clang to produce PE executables: Ultimate++ is a C++ cross-platform rapid application development framework :: Ultimate++[^] I guess the toolchain can also be used in other IDEs by playing around with environment variables.
-
What else is there to add? Honestly, how adept is the LLVM stuff at creating Windows PE binaries? Because I don't even want to deal with anything other than clang or gcc anymore.
Real programmers use butterflies
-
What else is there to add? Honestly, how adept is the LLVM stuff at creating Windows PE binaries? Because I don't even want to deal with anything other than clang or gcc anymore.
Real programmers use butterflies
-
Notice how it says *it controls* the Microsoft C++ (MSVC) C and C++ compilers. cl.exe is a command line control tool. It is not the compiler. Microsoft names everything development oriented with Visual, as Dar said. It doesn't mean it's literally visual. I blame microsoft's marketers.
Real programmers use butterflies
honey the codewitch wrote:
cl.exe is a command line control tool. It is not the compiler.
gcc is no different - and never has been. When you run gcc with the `--verbose` flag, it shows that compiling a C file to an executable runs the following: ``` /usr/lib/gcc/x86_64-linux-gnu/8/cc1 -quiet -v -imultiarch x86_64-linux-gnu a.c -quiet -dumpbase a.c -mtune=generic -march=x86-64 -auxbase a -version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccJEEoFg.s ``` This compiles the C to x86_64 assembly. ``` as -v --64 -o /tmp/ccAlIhSN.o /tmp/ccJEEoFg.s ``` Produces object code from assembly. ``` /usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper -plugin-opt=-fresolution=/tmp/ccaY47gl.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o a /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/8 -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/8/../../.. /tmp/ccAlIhSN.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o ``` `collect2` is what does the linking. cl.exe is much the same (although I think the compilation functionality is in DLLs, not separate EXEs - Windows doesn't have fast process creation with `fork`/`exec`, after all).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
What else is there to add? Honestly, how adept is the LLVM stuff at creating Windows PE binaries? Because I don't even want to deal with anything other than clang or gcc anymore.
Real programmers use butterflies
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](https://github.com/catchorg/Catch2/issues/1205), 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
-
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](https://github.com/catchorg/Catch2/issues/1205), 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
-
honey the codewitch wrote:
cl.exe is a command line control tool. It is not the compiler.
gcc is no different - and never has been. When you run gcc with the `--verbose` flag, it shows that compiling a C file to an executable runs the following: ``` /usr/lib/gcc/x86_64-linux-gnu/8/cc1 -quiet -v -imultiarch x86_64-linux-gnu a.c -quiet -dumpbase a.c -mtune=generic -march=x86-64 -auxbase a -version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccJEEoFg.s ``` This compiles the C to x86_64 assembly. ``` as -v --64 -o /tmp/ccAlIhSN.o /tmp/ccJEEoFg.s ``` Produces object code from assembly. ``` /usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper -plugin-opt=-fresolution=/tmp/ccaY47gl.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o a /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/8 -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/8/../../.. /tmp/ccAlIhSN.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o ``` `collect2` is what does the linking. cl.exe is much the same (although I think the compilation functionality is in DLLs, not separate EXEs - Windows doesn't have fast process creation with `fork`/`exec`, after all).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
sure, but the people who made the compiler call it GCC The people that made MSVC call it MSVC regardless of what the command lines are or how they are structured. The only reason this tangent happened is because someone argued that because cl.exe is called cl.exe that has to do with what the compiler is named. I'd argue it doesn't.
Real programmers use butterflies