As regularly happens, I found myself with wrestling to shoehorn SSE code into a codebase compiled with visual c++ 6 (from circa 1998), and realised I should be checking out the more modern IDEs.
I can already hear the *gasps* from the readers. Let me explain. I am one of the users of the earlier IDEs who has been most unimpressed by the later offerings of visual studio. I used VC5, and then when VC6 came out, it was fantastic, it offered code completion, woohoo! I used VC6 at home and at work, until at work we reluctantly decided to move over to 'Visual Studio .NET', sometime around 2003. I think it may have been because the xbox support stuff was moving to only support the newer visual studio, or perhaps a third party library, I can't remember.
Visual Studio 6
I can't remember all the problems we faced, but the main annoyance for me, and I've tried the various 'attempts' at improving visual studio over the years, has been how slow and unresponsive the thing is. I've constantly been amazed at how inefficient it is, I don't think I could make it that unresponsive if I tried.
On the other hand, the compiler itself has been vastly improved over the years, so I've been left with a kind of 'damned if you do, damned if you don't' choice of whether to 'upgrade', because the horrible IDE is forced upon you. Although it may be possible to shoehorn in a later compiler with the VC6 IDE, unfortunately you lose the debugger, because it does not seem to be compatible with later output files.
What do I need?
And so, while I've reluctantly used the later visual studios for various work projects, for fun stuff, I've mostly stuck with visual studio 6. Aside from some some bugs with class view .ncb files getting corrupted every now and then (which can be sorted by deleting the ncb and letting it recreate), it does pretty much what I want from an IDE :
- Fast classview with folders for working with large projects
- Fast and responsive to typing, moving around the codebase, compilation, debugging
I'm a big fan of SSE and things like OpenMP but I've mostly managed to get by compiling these into DLLs with the later compiler than calling them from the main module. And I appreciate the support for things like templates is better in the newer compiler but I've been willing to forego this for a quicker development environment.
2/3 years ago or so I did a quick test of the current IDEs of choice on windows, and found them lacking. I tried code blocks, QT creator, and visual studio 2013. The best of the bunch I found was QT creator, which very nearly ended up being my new 'go to' IDE, and I used it in a couple of projects. But I ended up back in VC6.
Anyway this past week I have been giving CodeLite, Code Blocks, QT Creator and Visual Studio 2013 another try and here are some of my findings. I am obviously not very experienced in any of them, and would love to hear that my criticisms are unfounded, and there is a way around the problems.
A lite IDE is exactly what I'm really after, without the bells and whistles, just something that runs fast. Unfortunately after a bit of trial, and despite it saying 'it works with major compilers', well yes it does, but it only seems to support GDB so I couldn't get it to debug code from cl.exe (the microsoft compiler). So that ruled that one out.
Despite looking a little 'technical' and harsh, I found it had lots of options and potential for instructing different compilers, and I set about converting my 3d Paint app to compile in it. Unfortunately while I managed to get the project to compile and run, it quickly became apparent that the debugging support seemed to be awful. It didn't even seem to display local variables. Don't get me wrong, I'm sure it is an achievement for the developers but for myself I need something that works. So I wrote off that day's conversion as a waste of time.
Next up was my pretty much favourite. I had tried QT creator before and pretty much love the design philosophy, it is what I would make myself if I had the time. It is fast, responsive, and doesn't show you 'too much' superfluous options, while still allowing you to tune under the hood. It works easily with cl.exe compiler, and support CDB debugging of the microsoft output code.
Again I spent some time converting. This time the actual code changes were more involved. I should explain that I'm a massive user of 'classview'. I understand that a lot of people (most perhaps) rely more on a solution explorer and organising by file, but I have always preferred to navigate with classview as it better fits the object orientated paradigm.
One unfortunate feature that was missing from QT creator classview was the ability to organise the classes from different libraries into folders. I believe this is what prevented me from fully converting over last time I tried it. But I did figure out that it would folder up classes correctly when using namespaces. So I went about changing my library code to namespace everything up.
All was proceeding beautifully until I had it all finished, and sadly found that the classview was not very good at showing up all the classes in the projects. Some would be missing. They would appear when I actually opened the files in the solution view, and it was 'half usable', but no good for navigating within the project.
One bonus of QT creator is that it is open source, and I did have a brief look at the source for the classview. It was all QT stuff (which I am not familiar with) and I was not really feeling brave enough to try and fix it, not knowing even the basics of how QT creator works. This is something I may revisit. Or perhaps the guy who wrote it (denis mingulov I think?) will improve it, but I think he developed it in 2010.
So after discussion in the forum here, I decided to give VS2013 another try, and try and figure out if I could cure the slowdowns. I had managed to find last time that a lot of the problems were due to the the background parsing of the codebase to give intellisense, and classview, but never managed to fix it to a usable state.
VS has grown to become one of the big daddy's of sprawling code bloated messes. I remember back in 98, the common thought was that most MS software sucked somewhat, but that visual studio was 'really good' and finally 'something they got right'. Well unfortunately they didn't learn from their success. In typical 'design by committee' fashion they seem to have tacked on c#, various other languages and flavour of the month technologies, which many c++ programmers aren't the least interested in. I'm sure there is a way of turning off all that 'stuff', but I'd rather not have any of it installed in the first place.
VS now seems to suffer from the 'too many options' problem. They clearly have so many developers working on it (independently and working against each other rather than together) that you can see multiple tools doing 'the same thing' rather than having some kind of coherent vision. Nowhere is the 'too many options' approach exemplified better than in the 'theme editor'.
The 'theme editor'. What were they thinking? Are they on crack?
The theme editor seems to have like 1000 or more options for customizing the colours of every conceivable gui element. To quote a wise woman 'ain't nobody got time for that'. I found myself spending 20 mins trying to find the option to change the window background colour, before giving up in frustration.
And now to the real problem. After googling and finding out that turning off 'graphics hardware acceleration' speeds up the IDE (you need hardware acceleration for a text editor? tell me more...), it looks like the main culprit for the awesome slowness in the new visual studios is the 'awesome' intellisense system.
Code Browsing Databases
It would seem that if you want to make an intelligent IDE that provides code browsing, classviews, intellisense etc, you have a choice, you can either rely on symbolic information produced during a proper compile, or you can run a 'mini-compile' that parses the source files separately and tries to maintain some kind of browse database. On cursory inspection it seems like all the IDEs have gone with the second option. This is great in that it can provide quick updates to the database without you having to ask for a compile, but it does have the potential for letting the IDE get into a tizzy about constantly re-parsing the source files, as we shall see.
What seems to cause all the problems with the need for re-parsing in c++ is that the result of a compile can depend on the particular #defines etc that are set at the time it is called. That is, one header could produce a myriad of different compilation results, even within the same codebase, depending on how and where it was brought in. This is both a powerful feature for developers, and a tricky problem for compiler / IDE writers. It would be much easier for compilation speed if headers were compiled once and just once. Instead, you get the situation where some users will vocally demand a '100% accurate' browse info database, which means these headers have to keep getting compiled and recompiled 'just in case'. Instead of giving us an option which would be ideal 'just compile it once and have a stab at it, if you get it wrong, no biggie'.
So now you navigate around your code tweaking bits here and there, visual studio is *constantly* recompiling, loading files, checking things (just in case you edited outside visual studio). Unless you turn the options off, merely waving the mouse over the source code makes this happen as it tries to produce those 'pretty' tooltips for you.
With all this 'background' (*cough*) parsing, I don't know about you, but it makes my IDE slow and unresponsive. Sometimes it just *hangs* while it figures something out. I keep telling myself, an IDE is just a glorified text editor. How did they make it so wrong?
I used 'processmonitor' to try and pin down what was happening, it shows you all the file accesses etc. It is really frightening. Anyway my current best solution is to turn off all the automatic updating of the browse database, and call 'rescan solution' manually every now and then. My browse database doesn't have to be PERFECT every millisecond, I just want to be able to navigate!!
Of course the fact this browse database is held as some kind of SQL database on disk doesn't help. Haven't you heard of using RAM MS? You know, it's cheap stuff and faster than disks? And you don't have to use SQL if you have a half way sensible access scheme?
I'm sticking with VS2013 for a little while, but once I've done my first release of my current project, I may have to have a look at either writing or modding an IDE, to get something that works properly. The simplest solution would probably be a modification of QT creator. But writing the whole IDE is not out of the question either. Scintilla seems to be a very good open source 'source editor' which you can integrate into your programs (it is used in the excellent notepad++ which I use as an external editor). It looks fairly easy to rig up an environment with a list of files compiling / linking with cl.exe, and displayed / edited with scintilla.
The only 'hard parts' seem to be parsing a code database, and integrating a debugger such as CDB. Myself I would be content with either reading a code database from .pdb files after compilation, or else doing a *very* lazy parse to give very rough classview and intellisense. I suspect CDB integration may be the tricky part, seeing as how much difficulty the code blocks developers seem to be having with it.
Well I came back from spending a few days away (without internet) to find there had been lots of interest in this topic (only a quick blog post not even an article)! I never thought anyone would actually read it :lol:, but clearly it struck a nerve, such is the power of the interwebs. It was very quickly written with no doubt many errors, and written slightly provocatively I'll admit, as a result of too many nights banging my head on my keyboard in frustration. I'm glad it got a little bit of discussion going though, as we programmers are totally dependent on the tools we use for our productivity, so if there's anything we should 'program right', or try to improve, it should be the tools that form the foundation of everything else we make. :)
Firstly a small caveat for my earlier waffle, I'd like to emphasise that I am but a lowly worm who can only speak for my own experiences, and the things *I* currently look for in an IDE, which is tied to how I currently work, and my small subset of knowledge of c++ and compilers. These considerations may be completely different with a big team, larger projects etc. So I would expect it to be difficult / impossible to provide a solution that is perfect for *all* users, who may have totally different priorities, and so my whining should be taken with a grain of salt. That said, a bit of constructive criticism isn't something we should be afraid of. I've done a lot of awful work in my time, and after dusting off my ego, criticism really helped pin down what could be improved so I could make it better.
I would also like to say that ALL the IDEs I reviewed here are GREAT in their own way and are massive achievements for the developers, and all are 'so close' to being my perfect choice, and my ranting is only because having an IDE at '98%' is sooo frustrating. I know that with that extra push they can be made even better for us users and make our lives much easier. And one of the many great things about us developer-type doods, is we do listen! :)
Visual Studio 15 Preview 4
Well on the advice of mluparu I have been trying out the preview of Visual Studio 15, as they had identified the symbol database as a problem and have been working hard on improving it. It looks like 10 months ago they rolled out a fix changing to a new database engine which appears to be making much better use of RAM:
All I can say is, WOW, they seem to have fixed it!! :D I eat my words and take it all back! It is now fast and responsive for me with the classview. So much so that I have already uninstalled VS2013. Obviously I need to do a lot more testing etc, but this is the first version for a *long* time where I'm hoping they may have got the formula right again. Very excited! :lol: