
C++ IDEs – a rant - douche
http://www.gamedev.net/blog/2199/entry-2262213-c-ides-a-rant/
======
viraptor
This article was interesting, showing a completely different world-view than
the one I experience. Compiler from vc++6? That's ancient! Misses loads of fun
C/C++ features (and I'm not even talking about the massive shift in new C++
versions). Sure, you can be productive even in c89, but why... These days I
don't trust code which doesn't pass modern compiler's all-warnings run, and
tools like clang-analyzer.

Author also has an interesting view of QT Creator development / doesn't seem
to be familiar with OS projects. "Or perhaps the guy who wrote it (denis
mingulov I think?) will improve it, but I think he developed it in 2010." \-
meanwhile 6 different people committed new code to the QT Creator in the last
24h.

There's a few more fun things to spot if you read carefully. But what I'm
saying is: it's worth remembering developers work in very different groups /
environments.

~~~
throwanem
> a completely different world-view than the one I experience

No kidding! I'm still bewildered and vaguely horrified by the idea that in
some worlds changing your text editor means you have to modify your projects
to work with the new one.

~~~
viraptor
While this is terrible, it can be easily explained at least. If your IDE
doesn't own the build process, you have no idea which defines are valid and
what's linked to what. You could monitor the build process to get that info
out, but that means you need one full build before your autocompletion starts
working.

~~~
solipsism
That's only because C++ makes this hard. It's not fundamentally true that
you're editor needs to own the build process to be a useful tool.

------
necessity
Why use an IDE, specially for C++? What's to gain from Emacs/Vim + Makefiles
(or CMake)? I used Eclipse for a while several years ago when I didn't
understand linking and it compiled and linked everything for me (same for VS
under Windows). I did not understand how Qt worked when I started using it,
but I could build semi working stuff with the Dreamweaver-like tools of Qt
Creator. Eventually I learned how to use it and dropped Qt Creator. CodeBlocks
is closer to Notepad++ than to an IDE for me. So... Why? But then again I
don't understand why people use C++ in the first place, my only use for it was
when working on projects built with it.

~~~
jackmott
To the first question: A rather well known C++ developer used to wonder that
too, until he got older, and couldn't remember everything about the language
and his projects in his head any more. At which point intellisense type
features began to make sense to him.

So if you can't see the use, you are either still extremely clever, or haven't
worked on complex enough projects to see how it could be useful.

Why use C++ in the first place - because not a single language/ecosystem has
come to exist yet that can replace it when performance is really important. If
you are trying to make Doom5, you can't waste a single instruction. You can't
miss the cache unnecessarily ever. You can't waste a byte of memory. You
wouldn't believe the kinds of things AAA game developers (or the developers of
the engines they use) have to do, to get done what they do.

Rust can't quite do it yet. D can't quite do it yet

Java/C# et DEFINITELY can't do it yet. And yes I know Unity uses C# for it's
scripting language, but someone has to make Unity.

~~~
douche
I assume you're talking about Carmack... Do you have the quote about
intellisense?

~~~
jackmott
not Carmack, I think he has always liked IDEs, even when he was young.

Won Chun is the guy I'm talking about.

------
jackmott
Visual Studio 2015 Update 3 has some performance improvements and some big C++
compiler improvements.

You can also make it less visually 'noisy' with some of these settings:
[https://jackmott.github.io/programming/tools/editor/ide/visu...](https://jackmott.github.io/programming/tools/editor/ide/visual/studio/2016/07/11/decruft-
visual-studio.html)

~~~
PretzelFisch
visual studio 2013, represents the point where vs was pretty usable for c++
again, 2015 is better. But they both pail in comparison to how quick vc++6
was.

~~~
jackmott
Yeah I know, but on a modern PC, with the latest VS and silly settings turned
off, I'm not often annoyed by slow UI issues. I know some people who use the
debugger a lot are annoyed more often than I am.

~~~
MaulingMonkey
The only thing worse than debugging in VS is debugging in any other IDE - or
even worse, via the command line.

------
rhodysurf
Clion is decent, especially if you work with cmake. Kinda sucks you cant get
the functionality as a plugin with IntelliJ.

~~~
michael_h
I wanted to like clion. It is so good _looking_ and had the standard set of
jetbrains magic, but wow is it slow. If I'm trying to wrestle the ideas from
my brain and squash them into the editor, and then I'm suddenly interrupted
with another line of thought wondering what this beautiful IDE is churning
away at and I hope it's getting all these keystrokes that aren't appearing
yet...that's not going to work.

~~~
rhodysurf
Agreed. Thats my problem with pretty much all the jetbrains IDEs. I have a
high specced modern MBP and its still slow and the UI locks up. Meanwhile VS
and Xcode preform awesome.

~~~
jen20
I've had the exact opposite experience - all the JetBrains IDEs have been
super responsive, whereas Visual Studio could never keep up with moderately
fast typing and regularly hung for minutes at a time.

------
brian-armstrong
If you really care about the process and how everything works, I don't see how
you can beat vim/emacs + command-line. Ultimately text interfaces will always
be easier to manage and give the lowest resource utilization

~~~
MaulingMonkey
> If you really care about the process and how everything works, I don't see
> how you can beat vim/emacs + command-line. Ultimately text interfaces will
> always be easier to manage

A few things I think text interfaces are, or tend to be, terrible at:

    
    
      Profiling information (can't beat flame graphs)
      Graphics debugging, previewing UI layouts (text is terrible at displaying the results of pixel shaders)
      Discoverability (VS has so much UI up front to discover that it's literally overwhelming for some, a vim user will hit the manual to figure out how to even get into insert mode...)
      Manipulating and viewing many tree and node based structures (shader graphs, parallel stacks, ...)
      Even basic scrolling (map style scrollbars are wonderful for large files in alien codebases...)
    

Even basic intellisense requires text interfaces to awkwardly pretend they're
a real user interface with ncurses or the like. VS has it's drawbacks - it's a
hard-to-extend monolith, there are too many blocking operations are on the UI
thread, it hits the disk too much, etc. - but I've seen these issues in text
based tools as well. The problem isn't that it should be text based.

> Ultimately text interfaces will always [...] give the lowest resource
> utilization

I want to _maximize_ the useful utilization of my time. "Lowest resource
utilization" is not a goal. "Most efficient resource utilization" might be
getting there, but I'll happily eat some wasted CPU time on the off chance
it'll mean less wasted mind time. Powered down silicon is a wasted investment.

~~~
throwanem
I mean sure, if you're manipulating data that isn't textual, you're going to
want some non-textual interface to it. Code is text. Editing it as text makes
a lot of sense.

As for your points about map scrollbars and completion UI, I can't speak for
Vim, but Emacs has had graphical capabilities for a long time and does both of
those things quite handily. I don't see the point of map scrollbars and I use
code completion only sporadically, but they're there if you want them, as are
many other perhaps surprising things, and Emacs doesn't feel a need to show
off and get in my way as I've found more heavyweight tools like Visual Studio
to do. (And what a world we live in, where _Emacs_ can reasonably be called
lightweight by comparison with _anything_...)

------
AdeptusAquinas
I wonder if with the new ref improvements in C# 7.0, there will be more
adoption of it for game development (even amongst these sort of C++ people,
who think C# is 'tacked on' to VS, rather than it being the other way round).

~~~
sssilver
Game development, as far as cutting-edge AAA-looking games, will never adopt a
language with automatic memory management.

I guess Rust is the only language that has a fair shot at that right now.

~~~
fpoling
Swift uses reference counting and does not suffer from latency spikes. So it
can also be used.

~~~
sssilver
Reference counting is still a form of automatic memory management and has
performance implications. Remember, when dealing with data volumes along with
performance constraints of a typical modern video game, cache misses are
CRITICAL.

------
atemerev
There is also CLion — an excellent C++ IDE from always brilliant JetBrains.

------
mbgaxyz
Netbeans is pretty good:
[https://netbeans.org/features/cpp/](https://netbeans.org/features/cpp/)

------
ausjke
[https://www.cevelop.com/](https://www.cevelop.com/) this one works well for
me.

------
curiousDog
Source insight is pretty good although it's more an editor than IDE

------
michaelvoz
Xcode is an absolutely amazing C++ IDE! I wonder why the article did not
mention it?

~~~
sssilver
OMG, please no. Xcode is one of the worst and most buggy IDEs ever. The sheer
number of times one has to restart the IDE, clean up the "Derived Data", go
through git merging clusterfuck because of Xcode's peculiar project file
format is staggering. In addition to all of that, it's extremely stateful, so
when you are having problems it's almost impossible for your colleagues to
reproduce them on their instances. With every new release of Xcode I hope the
Xcode team has understood and fixed these basic problems, but all they mostly
do is just introduce new bugs. Xcode is the single worst aspect of my daily
programming.

~~~
michaelvoz
That has only been my experience around swift. Have you used it for C++?

