I'm not helping until I know why you're using C++, as it's the wrong choice for 95% of projects that come up on these forums, it's harder than almost any other programming language and walking you through the setup is going to take quite a while.  A list of compilers isn't going to help you, and you're probably going to need command line familiarity and will need to learn Cmake or something similar pretty early.
The short answer is install visual studio express, install a build system, launch a developer command prompt, and use said build system to manage your project once it gets bigger than a file.

because MinGW gives you access to like 2/3 of the Windows API at most, with crucial things missing almost at random.  It's also a *lot* harder to set up if you don't know how these days, as they've moved to a installer with some interesting but not insurmountable accessibility issues.
If you are on Windows and you are not porting software from Linux, then just use VS.  It's not worth the trouble, and it seems that MS has picked up the ball in terms of implementing new C++ features anyway.

Post 2 is completely justified.  Getting C++ to even work in the first place as a blind person is an incredibly fiddly and difficult procedure if you don't know programming, and better options for first programming language include basically everything else.  If there is a justified reason to go through the process, then I will help, otherwise it's not worth me writing up directions on using at least 2 different pieces of fairly nontrivial software, one of which is basically a second programming language (really. Pick a build system, they all are these days) and both of which are almost certain to spawn yet more questions and frustration.  I'm not trying to scare anyone away; the problem is that honestly talking about C++ is scary no matter how you slice it and I refuse to lie.

*sighs*
Look, Ethin. Why are you just trying to scream at all people? Well, camlorn warns the first poster, is he doing anything wrong? I don't think so.

I have commanded no one to do anything and even provided an abbreviated answer in post 2.  If you do not have the knowledge to set C++ up, explaining the intricacies of getting to the point of actually being able to do a project is a very time-consuming task, simply in terms of setting up and learning/teaching the needed tools.  The original poster could have come back and said "I am sure this is what I want, here's why", and I would have/still am more than happy to help.  But it's not worth generating several essays of content without some assurance that this is more than a whim; if it's a "I want to learn programming" type of thing, there are many simpler places to start that don't require me to teach programming just so you can properly use a build system.
Please stop jumping on me for warning people off C++ and start considering that I have been developing almost exclusively in it for 2 years now.  I think someone that has used a language for serious mathematical and CPU-intensive coding for 2 years up to and including consulting  the C++ standard on many occasions is qualified to say how horrifying or not it is.  C++ is something that you use when you need speed but have a problem complicated enough to warrant a fairly high level of abstraction, and the consequence is that every single feature of the language sacrifices simplicity for the ability to have your compiler spit out efficient assembly language.  It also has a number of features (hello, move constructors, compile-time template metaprogramming) which exist only to allow you to write faster code.  If you think Libaudioverse or my C++ knowledge is trivial, just come out and say so and we can discuss it.  But I would say that I'm one of the most qualified on this forum to discuss this particular topic.

First, yes, I can actually do everything I want in Go or Java.  Both are fast enough for DSP, provided that one does not wish to build a library that can be used from multiple other languages.  I can also do everything I want to do in Python, if I'm willing to go the numpy/scipy route.  If you want to get technical, there are even cases where Java can be faster than C, but this requires a very, very carefully crafted benchmark and is rare to nonexistent in practice. The only place that C+ has a major advantage is advanced 3D math, and this is only because the industries that need advanced 3D math (read: cinematic quality video games) are building on 30 years of code from other people in the same industry, and some of it trickles out into the open source community because people are nice sometimes and do that.
It is easy to get a C++ compiler going and to compile hello world, at least if your definition involves downloading Visual Studio.  Cygwin and MinGW require more setup and don't give you access to all of the Windows API.  Anything beyond hello world for either C or C++ requires a build system or spending several minutes every time you want to build the software.  Such build systems are second programming languages in all cases I'm aware of.  Some are even developed for and tied to specific projects.
Your comments about C and C++ are indicating that you do not understand the purpose of the languages, or really even that C is a subset of C++ for all intents.  Go code us a game in C++ using C++ as C++.  That is, don't just use the C features and call it a day.  I'm not even sure where to start with this debate, and I honestly don't want to have it.  The problem I have here is that you are publicly all but calling me an idiot while providing information that is demonstrably not true, and you have finally done it on a subject I am definitively very qualified to know about beyond all shadow of a doubt.  I do know C and C++ backward and forward.  That's what happens when you seriously use a tool for a project that involves over 50 files and, as of right now, about 7000 lines of code.  it's also what happens when your entire CS curriculum uses it for your entire college degree, due to being at least somewhat behind the times.
No one reads the standard back to front.  No one.  The fact that you think this is an appropriate comment indicates that you probably haven't even seen the really dense parts of it, where it degenerates into something that is almost discrete math and you have to cross reference 4 or 5 sections to figure out if the thing you want to do is "allowed".  I have never claimed to do this, because it's a normative document and consequently not intended for that purpose.  You consult it when you wish to know if something that works on X86 and using Visual Studio is going to work elsewhere, not because you want to know how something works semantically.
In future contact me privately, if you have a personal problem with me.  Otherwise, if you think I'm wrong, just say so outright.  Attacking me publicly helps no one and gets nowhere.  It also leaves me without many good options; I'm not going to allow you to drag me through the mud like this without responding to you.  I thought we had managed to come to some sort of tacit arrangement and that this was over, but apparently I was mistaken.

Everything I said above holds.  But this thread isn't going to go away until someone gives an answer, so fine.  This is still the brief version.  The long version is multiple pages, including a Cmake tutorial and a Cdb tutorial.  If you have a proven performance problem in a higher level language and have tried everything else to fix it, then it's time to maybe consider C++.  Maybe.  But there are other, more sane languages out there, and you can usually find C/C++ libraries for whatever language you're in that do whatever you're trying to do, anyway.
You do use the compilers from the command line.  I can even get you started debugging, though that would almost certainly involve some sort of realtime discussion because it's a bit fiddly.  i'm not familiar with the various free editions of VS, but they all contain the same compiler as far as I know; I use 2013 Ultimate, which I get free due to my university and which has no practical extra features if you're blind anyway.  As far as I know, 2015 isn't out yet; if that's what you're looking at, wait.
The trick to using the command line compilers is to find the developer command prompt.  Every version of VS moves this somewhere slightly different; you'll have to look up where it is and make a desktop shortcut to it.  If you can get that far, the compiler is cl.exe, the linker is link.exe, the debugger is cdb.exe if you installed it via the Windows SDK, and you may also be interested in dumpbin.  Cdb will not help you without a lot of fiddling or asking me, so you have been forewarned.
After bouncing around between build systems, i finally settled on Cmake.  Cmake is like PHP: it's completely awful, but you're not going to outdo it in terms of being able to get things done and cope with the fact that every system is different.  I'm not going to even go into platform-specific options.  I looked at Scons and seriously used it for camlorn_audio, but you literally end up spending longer waiting on Scons to run than for your source files to compile; it is also not very actively developed.  Everything else I found doesn't even have the abilities that Cmake does to cope with finding where things are, so putting up with one of the worst programming languages ever is the price you have to pay.
The final piece of this particular puzzle for a Windows user is Jom.  I don't have a link.  It's part of the QT project of all things.  You can use Nmake or Msbuild, but Nmake only uses one core and Msbuild gives you so many status messages it's ridiculous.  jom is able to build with all your cores while not having that problem.
And this is still the brief version.  Really.  Cmake itself is a full programming language and cdb is essential if you want to know how or why your program is crashing and involves at least 15  2-letter or 3-letter commands without useful mnemonics.
And don't think you can forgo a build system.  Libaudioverse is only 7 kloc.  A full rebuild takes about 2 minutes.  A full rebuild with the supporting libraries which are in C and consequently compile faster is upwards of 3.  I'm literally going to be purchasing a high end computer just to get these down; as it stands, they take half the development time or more.

Jom is supposedly compatible with Nmake, but Cmake has a specific generator for it that does who knows what and there's no reason to write the files directly.
Enjoy is an interesting word choice.  For some real fun, go read the Libaudioverse build scripts.  There are a couple things in there that took a good while to work out, though some of it is to do with the fact that I'm generating an additional couple thousand lines of code using Python and Pycparser; regardless of the chosen generator, some file must unconditionally be in the same place.  Cmake is the best cross-platform build system out there in so far as I can find, but you've not seen the complexities you get into with it unless you've tried to get your stuff building with even slightly complex requirements on Linux and Windows at the same time.  And for that reason, I'd not call it great.
But my point here still stands-C++ is not one programming language, it's two programming languages plus a number of tools with complicated interfaces.  If you can program and are truly sure that C++ is what you want, I can't and won't stop you, even if I do expect you to come back and say I was right at some point down the road.  Have to use, maybe.  Want, never.  But for new programmers, it's as far from the place to start as you can get.

Okay. Look. C++ is the same speed as C on average.  If your compiler makes C faster, that's the fault of the compiler and not the language.  This speed difference is a myth.  You can do slow things in C and you can do slow things in C++, but I've got a sizable chunk of mathematical code that I moved from one to the other with no difference (and yes, I had a measurement program to check this).
If you manage to start calling the copy constructor everywhere, yes, you will come away from it thinking that C++ is slower; in reality this is not what most programs do and you can replace much of it with const references.  For C++11 specifically we now have the move constructor which, when implemented and used properly, makes returning std::vectors of millions of items nearly free.
The reason for which c is still used for OSes are complicated, but basically boils down to legacy code and the fact that C compilers are about 1000x less complicated and monolithic than C++ compilers.
If we want to say anything about C++ versus C in terms of speed, then we may say this.  You get what you pay for.  If you use copy constructors and everything from the standard library, bring in boost, and generally don't know the language well, you'll pay for it in speed.  The biggest offender may possibly be virtual methods where the method call itself is so trivial that the overhead of the vtable is noticeable.  But assuming that you can even find a case whereby C++ sows up as slower than C I can promise two tings: it will not matter at all and it can be optimized if it must be.  In addition, for the specific case of the standard library, your compiler will often optimize most or all of the overhead away.
We are well past the days where the C++ compiler is worse than the C compiler.  We are even further past the days where the C++ compiler compiles to C and then calls the C compiler.  The speed is the same in all cases where it matters and you may always choose to stop using the abstraction if you really have to.

@Narra, for simplicity, learn a basic dialect. FreeBASIC is a good alternative to C/C++. Go is good, but requires you to code in a specific coding style and is meant for servers and datacenters; Java is a very advanced and (in my opinion) stupid programming language; Python is good for indentation-liking people (me included (not the text editing part, but the coding part)). There are hundreds of programming languages out there; pick the one yo ulike the most and stick with it. Change if necessary.