If the OP really wants to learn then a close to ideal way is build the files in a command line and use a plain old text editor such as Gedit or Notepad++.

If he start with either you or my professional choice in IDEs he will have a ton of neat details to explore that will do him no good but can easily break his setup.

Eventually he will want an editor that can launch a command to do his build for him and he will learn the how and whys of IDEs. As his project gets bigger he will start a shell script or batch file and intuit why build systems exist.

He will learn the kinds of problems that come from software and not be bogged down by a bunch often useless details in professional tools until he needs those details. By the time that happens those details can't help but be useful.

> I'm pretty sure you can change these things in the project settings.

Those things could be changed, in the current versions it is easy, but in the version from from around 2012-2014 it was a huge and it would automatically be changed back if you selected certain items from the menu. Not all project have the luxury of being able to be up to date. Particularity in shops that have bought all-in to the microsoft philosophy, where tools cost an inordinate amount of money for no reason I and suss out.

> Each new version of Visual Studio usually includes new core language features

And they are slower to get the features if they ever get them, unless they lead development I am sure it A+ module and co-routine support but msvc 2015 rev 3 didn't have thread_local and every other compiler did. This is the kind of you can replace with a macro I had to rewrite an algorithm to make work it on that compiler.

If I want to ship a source library and want people to be able to build it on msvc, I pretty much don't get to use thread_local even though it enables a bunch of really cool things. This is just my most recent pain. I have written many things that worked great on the 3 PC platforms as long you weren't using msvc, but as soon as you switch from mingw to msvc something ridiculous broke. Whether it be the preposterous macros set in windows.h or the completely unique semantics for their very bad pre-compiled header implementation I have to deal with a break on just windows/msvc about every two months. Good luck dealing with std::uncaught_exception or any other feature that super useful in niche circumstances.

> Yes, I think it's been there for a very long time (just switch the runtime library to "/MT" if I'm not mistaken).

Except it doesn't enable static linking, like you said it switches which library you build against and some things are still dynamically linked. This non-sense is also all bound up with debugging and thread support. Every other compiler lets you choose these option independently but with msvc you have to choose one of 4 /MX flags and hope its good enough.

On /W4 and /Wall I am cool with all manner of errors being found in my code. I expect that and even some spurious ones. What I don't like is the huge amount of non-virtual deconstructor noise coming from the std library or other warnings from headers that the compiler controls. Those should either be fixed or exempted from warning generation. I have never gotten a warning from Gcc or Clangs std library, I don't know how they do it, I don't need to, but with a sufficiently high warning level and all warnings as errors I need to wrap certain includes like <vector> in pragmas to disable warnings. I now understand why some windows devs think coercing all warnings to errors is a bad idea that can only hurt productivity, because with their tool-set it is.

> Funny, for me it was exactly the opposite

Then, I suspect your builds are simple. As soon as a project needs to do things like support multiple platforms or multiple compilers or even needed to generate code as part of build the menus become pretty limiting. You can run arbitrary build steps using the menus in visual studio, but it is a pain. If you want to use SWIG to generate bindings or configure Doxygen to generate API docs and get the errors from it in your IDE the difficulty level gets super high.

That might not affect a fresh minted developer still learning, but the other side of the massive menus is that if you don't know what those options are or do finding the option that changes some behavior involves a huge amount of googling. That itself isn't bad if it can be avoided, but inevitably all that googling gets you to the msdn or technet, the two worst piles of shit for documentation and answers on the internet. And every one links to them. They are often stale, contradictory, light on detail or just plain wrong.

This never happens with CMakes docs (sometimes they are light on detail but then there is stack overflow) their docs are versioned, skill with one version moves with you to the next version and it is the de facto standard for projects not mired in vendor lock-in so there are countless examples of CMake project to learn from. Plus it is a full blown programming language so if you need to do something unfortunately interesting in your build you just do it, wrap it in a function to hide, document it and move on.

This is turning into a msvc vs cmake showdown. This is apples and oranges and needless I won't participate further other than to say the community has spoken and CMake is the build system of choice and visual studio is the IDE to use on windows.

> I think you can customize your installation to take less than 20 GB.

You can; I was almost going to say I was speaking in hyperbole, but no I meant 20GB. I have seen isntalls in excess of 45GB... Who the hell needs 45GB of IDE and compiler.

The problem with trying to get smaller installs is that the menu options in the installer are undocumented or poorly documented to the point that someone who has painstaking researched it needs to give you a list of boxes to check for your project or you include a bunch of needless BS.

Even if msvc were a pleasure to use I probably wouldn't at this point. Too many times microsoft has tried to screw me. They are just a horrible company and treat people poorly. Sticking in the space of compilers and IDEs they made too many technical decision for marketing and vendor lock-in reasons for me to trust them again. Their tools sucking just make it easier for me to avoid them, if they released stuff with the quality of Jetbrains or Qt I would have a harder time resisting.

It seems you were overly polite, so you may have misread my post. I am not angry with you as you have been quite cordial and earnest, but please reread my post with your internal voice screaming and deeply enraged as though you just saw an orphan, a puppy and a baby seal all run over by a lawyer driving a hummer that is "rolling coal" fueled only by endangered redwood chips who works for patent trolls and is on his way to defend a giant oil company's right to defraud the founders of a tiny tech startup in a totally skeezy but technically legal way. If your politics don't lean that way, then you will need to settle for the phrase "Please, reread that in an extremely angry voice". These tools that microsoft makes have caused me many years of pain and will continue to do so even though I heavily invested in open source, and I have wished many times for a button I could push to make them all disappear.

EDIT - Have an upvote for remaining so polite and attempting to help me fix my problems, even thought we are well past that.