For standard C++, it shouldn't matter. However, it's easy to make assumptions that are not part of the language...and which may differ from one compiler to the next.
Sometimes, it's not the programmer's fault. Not the first time, anyway. Visual C++ Express has a quirk that if you create a project as a "C++>Win32 Console Application", you get started with a "hello MS world" main program that will *only* compile on Visual C++, and won't compile if you wipe everything out and replace it with a legitimate C++ main function. Best is to delete the project and start over with an Empty Project.
GNU C++ allows C99 variable length arrays, even though they are not part of even the latest C++ standard (2011). You can prevent that with a --pedantic compiler switch, but that's not the default setting. You could import a modern C source, fix up the C vs. C++ differences to get a working program under G++, but won't compile in VC++.
Some things are just not defined by the language. The following bit of weirdness:
!(cout << "left ") | !(cout << "right ");
is perfectly standard, but may output "left right " on one compiler, and "right left " on another. C++ does not specify the order in which arguments to a binary operator are evaluated. Either way, or even "lrieghf t " is possible.
I have developed a habit of (a) turning off compiler extensions, and (b) turning on all warnings. Then I make sure that each source compiles without warnings. As a self-check, I'll take all or part of a project and compile it on another compiler, just to get another set of checks. As time goes on, the number goes down, but I still find myself unintentionally producing non-portable code.
So, if you have problems moving code from one compiler to another, check your own code for portability.
MinGW isn't an IDE, by the way, but it is the best windows native port of the GNU compilers and related tools. You can use the MinGW "toolchain" with IDEs like Code::Blocks, DevC++, Eclipse and NetBeans.