|
She had a crappy computer that was real dirty so I used canned air and cleaned it up. After that it wouldn't boot so she had a really old crappy machine that we got up and running so she would have something. So I'm not real worried about the mouse problem because the computer she's got now isn't worth getting stressed over.
|
|
|
|
|
|
Can't read the linked item - it is asking for me to allow it to see my Location. Why?
I have never allowed anything to see my location. My PC is a desktop and does not have any location detection on it.
|
|
|
|
|
|
"Terminated, might newspaperman shortly have taken complete control?" (11)
[Previous and this is not my creation.]
|
|
|
|
|
Terminated OVER
might POWER
newspaperman shortly ED
have taken complete control?
OVERPOWERED
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
modified 17-Mar-21 9:15am.
|
|
|
|
|
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
modified 17-Mar-21 10:17am.
|
|
|
|
|
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. 
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
|
|
|
|
|
honey the codewitch wrote: I'd argue it doesn't.
I agree with you - I always call it MSVC, CMake refers to it as MSVC, seems legit to me.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
What then is the difference between cl and gcc?
|
|
|
|
|
C++ compiler support - cppreference.com[^]
While the MSVC compiler has improved significantly in recent years it still lags:
Note all the asterisks next to the C++20 library and language features.
The bottom line is those are partial or otherwise "supported with qualifications" which at the end of the day means your standard C++20 code might not compile for MSVC without conditional compiles.
Like I said, it has gotten better, but so did internet explorer before it was replaced.
I prefer to be able to use -std=C++20 and be confident that my standard code will compile, or if it won't, then it's *my fault* - metaprogramming is difficult enough when you know what you're using is fully supported. If it's not, tracking down the error can be a nightmare - I speak from unfortunate experience.
Additionally, the fact that MSVC consistently lags behind in standards support by years (i'm not saying lags behind other compilers, I'm saying lags behind the standard itself) means if I want my code to compile across compilers I have to dumb it down for the lowest common denominator.
And between the major compilers, that lowest common denominator comes up as MSVC. I guess some compiler had to fill that role, but they were going to be my target whoever they were, because they're going to be the reason that I can't have nice things.
Real programmers use butterflies
|
|
|
|
|
Most of those asterisks seem to just show a different kind of version number.
20 years ago, MSVC lagged seriously behind the standard (I'm talkin' to you MSVC 6). Today, conformance is excellent, though for a given feature it may take longer to get into MSVC than the open-source compiler in which the feature was prototyped (duh). I'm comparing compilers for a book on optimization, and so far I haven't encountered a situation in which the three compilers didn't all support a feature, though I accept that they exist.
There are in fact differences in the way the compilers interpret the standard, but this has always been more a bug in the standard than in any of the compilers, or a situation in which one compiler accepts a more generous (nonconforming) syntax than another.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
