next »

[zantifon]

I would argue that the quality of the debugger is by far the highest priority. I usually end up spending a looooot of time debugging. Thus the IDE being used is very important to me.

Both the GCC and MSVC compilers support enough of the C++ standard that most programmers (especially ones new to C++) aren't likely to be using any of the esoteric features not supported by both, and both generate code that is quite fast enough for anything I usually write. If I'm honestly getting benefit I can't live without from vectorizing 4 multiplications, then there's probably something else wrong with my code. Besides, last time I checked, GCC had next-to-nothing in terms of whole-program optimization, and so MSVC often ends up generating faster code for me than MinGW.

All that aside, if I'm learning C++ I don't give a crap how fast the compiler's code is. A good debugger is infinitely more useful to learning the language than a vectorizing compiler.

So the only consideration for me is which has the better debugger. And while Visual Studio has a lot of annoyances that Code::Blocks (or just using a terminal and Make) does not, Visual Studio definitely has the best debugger I've ever used, bar none. So on Windows I stick exclusively with Visual Studio.

On Linux I stick with vim, make, and gdb.

[Gold Cray]

On Linux I stick with nano and make.

fix'd

[Ivan]

As someone who constantly compiles stuff across platforms I can say that the fact that gcc is used on every other platform except for windows (aside from mingw, natch) and the msvc compiler frequently has issues with things that gcc does compile (although it's gotten infinitely better with compatibility over the years) is pretty annoying. It's not game breaking though, and with a few tweaks I can almost always compile my stuff.

As for IDEs, I am completely spoiled by Xcode. MSVC is nowhere near as fast, intelligent and debug-friendly as Xcode. But, well, you know, thats just, like, my opinion, man.

[Impossible]

MSVC is currently one of the most standards compliant compilers available and has been since Visual Studio .NET 2003. The biggest outstanding issue is two phase name lookup, which unfortunately will still be be supported in 2010.  Its unfortunate that this has been a problem for you, object_0, but its obviously not a major issue for most developers, even those writing complex template code.

There are a handful of other things not supported or purposefully not compliant, as well as a lot of MS specific extensions clearly marked as MS specific in documentation.  This seems comparable to GCC, which has non-standard compliant functionality and its own set of compiler specific extensions.

Visual Studio 6 was notoriously bad though. There was basic template functionality but it was only there to support the STL implementation at the time.  I can see where you are coming from if most of your experience with Visual Studio is circa 2000.

I think the lesson learned in this thread is... If you have an admitted anti-MS bias, use Code::Blocks with MinGW because M$ sucks, otherwise use Visual Studio 2008 Express .  Of course, if you dislike Microsoft why use Windows at all?

[Average Software]

MSVC is currently one of the most standards compliant compilers available and has been since Visual Studio .NET 2003.

The last version I used was later than 2003, I don't remember which, but whatever version it was still didn't parse template code prior to instantiation.  For example, it would happily accept the following:

Code:

template <typename Type>
void Funk()
{
    lsdsdafhjfsdahfauhae
}

You wouldn't get an error message until instantiation.  G++, Intel, and Comeau all parse templates to look for errors prior to instantiation (as required by the standard) and catch errors while the template is still in generic form.

Does VC++ finally require the use of typename in templates when referring to dependent nested types?  This is another one that burns programmers coming from VC++ to other compilers.  Last I knew, VC++ would accept this illegal code:

Code:

template <typename Type>
void Funk(std::vector<Type> v)
{
    std::vector<Type>::iterator i; // Illegal.  Requires typename before std::vector<Type>::iterator.
}

I follow the GCC mailing lists, and not a month goes by without someone reporting this as a GCC bug when it won't accept this code, ported from some VC++ project.

To call VC++ one of the most standards compliant compilers is really stretching it.  Intel and Comeau are both based on the EDG backend, which is basically 100% compliant, even supporting the export keyword.  G++ is way ahead of VC++ in proper template support.  The only other major supported C++ compiler I'm aware of is Borland's, and I think they basically mirror VC++'s policies.  Unless there are a whole bunch of supported C++ compilers that I'm not aware of, VC++ is one the least compliant compilers out there.

Of course, I haven't touched it in a few years, nor do I plan to.  Maybe it's gotten better.

[oahda]

I find it very comfortable to be able to use the same IDE for all systems, since I work with portable code, always (C++). I use Code::Blocks.

I'm about to get my first Mac now, though (hopefully delivered by tomorrow), and I might use Xcode if I like it. I'll have to see.

[skyy]

Long time visual studio user here, never tried the Express edition and never will. Before VS I used to roll with Dev-cpp which I cannot recommend to anyone and after that Code::Blocks which is a lovely piece of software and server me well for it's time. Still love it and have fond memories of it. But now.. VS.. Not going back, not moving forward Just waiting for VS2010 release.

All though when I'm going to move to Mac side I will have to let go of VS unless I emulate win and run VS through that but that sounds silly... But hey, you never know lol.

But definitely try out few different IDE's and see what rubs you the right way. 

[Xecutor]

I vote for Eclipse CDT!
Code completion and semantic highlighting of CDT is AWESOME!
Unless you are running really really old PC, Eclipse will run just fine.
Dispite the fact that it's written in java, they optimized it very well.
I'm using it on mac mini with 1.6Ghz CPU, and runs well.
There is some highlighting delay in case of really big files,
but editing is not slowed down by this delay.
And you can turn off semantic highlighting for big files.
On work I'm editing my files on mac with Eclipse CDT,
and invoking make on solaris server via ssh.
It's possible to configure custom errors/warnings parsers.

Eclipse is very well supported and evolving quickly.
I submitted several bugs and they were fixed.

I tried many different IDEs before Eclipse.
IMHO all other IDEs are on totally different level.
Give it a try.
It takes some time to configure everything to your preferences,
but once you'll make it, you can really enjoy conding in it.

There is also Visual Slick Edit. But it's commercial.
Our company had linux license of previous version.
It can be very well configured and extended via builtin
scripting language, but code completion and code navagation
is somewhat flowed.

[Mikademus]

Does VC++ finally require the use of typename in templates when referring to dependent nested types?  This is another one that burns programmers coming from VC++ to other compilers.  Last I knew, VC++ would accept this illegal code:

Code:

template <typename Type>
void Funk(std::vector<Type> v)
{
    std::vector<Type>::iterator i; // Illegal.  Requires typename before std::vector<Type>::iterator.
}

As compared to older versions, VC9 adheres more to the typename requirement, but the code above still compiles and runs.

Nonetheless, another thing to take into consideration is that most Windows versions of libraries are expected to compile against VStudio/MSVC, and it can be quite messy to get them to compile on other IDEs/compilers. It may simply be more effort than it is worth. I use visual studio, but I really dislike some of the nefarious MS proprietary lock-in policies sneaking into the compiler, like generating "warning, strcmp/strcpy/etc are unsafe and deprecated, use our M$-specific strcmp_s/etc versions instead".