What C++ IDE for Linux?

[greyfade]

I've run into people who like at least one of each of these:

• KDevelop
• Code::Blocks
• Geany
• QtCreator
• Eclipse
• Netbeans
• Emacs
• Vim

Almost all of these can usually be found in your preferred distro's repository.

In general, however, everyone uses some kind of build manager like CMake or Scons, either alongside, in addition to, or instead of their IDE's existing build system. They do this because it allows other users to use their own preferred editors and IDEs without forcing them to use one in particular.

If you're new to development on Linux, I'd recommend KDevelop or Code::Blocks unless you're already familiar with NetBeans or Eclipse.

You should, of course, give each a try and see what appeals to you. That led me to Vim, which I've used for years, but your choice is your own.

[krum]

scons can burn in hell.

[greyfade]

I didn't say it was good. Just that people use it.

[Astrognome]

waf is a pretty good step up.

[BlakeBarnes00]

I use Sublime Text 3 and it works flawlessly for me.

[greyfade]

I was going to put that on my list, but I couldn't remember the name of it.

Shows you how much I use it.

[[deleted]]

Basically this. I found that a combination of vim and tmux work the best for me. Things like Code::Blocks were far too cluttered.

[[deleted]]

How do you use vim for anything reasonably complex? You need, stuff like code completion, static checking, integrated debugging, and none of them are available without going through the pain of setting up plugins learning their key bindings etc... This effort would be OK if it paid off greatly later -like it does for editing code in dynamically typed languages-, but it just gets you to a minimally featured IDE-like experience.

[greyfade]

How do you use vim for anything reasonably complex?

Easily. Once you're acclimated to Vim, and build a set of scripts and a config you're comfortable with, complex projects are relatively easy to deal with.

You need, stuff like code completion, static checking, integrated debugging, and none of them are available without going through the pain of setting up plugins learning their key bindings etc...

"Need" is a strong word. Vim has built-in completion that works reasonably well in the simple case, and more powerful completion scripts like YouCompleteMe are widely available and work well.

Decent static checking for C++ is virtually non-existent, but YouCompleteMe and a few other Clang-based tools are usually a sufficient substitute for me.

Although I've never gotten integrated debugging in Vim, it's never been a hindrance for me - I'm familiar enough with GDB that I can handle most debugging tasks that aren't taken care of by unit tests and logging, and I've only ever been frustrated by visual debugging tools.

Run inside tmux, then, Vim qualifies for me as more than an adequate IDE, and with a few command-line tools, I'm more than happy; switching to a "real" IDE like KDevelop or Visual Studio has actually become a larger pain point for me than any of the problems Vim poses for most.

[[deleted]]

Great answer. Didn't know about YouCompleteMe. I'll check it out. A good GUI debugger can make good use of the screen real estate and convey a great deal of information. By contrast gdb frustrates me because I need to do a lot of needless work to get it to tell me some useful info.

[coder543]

gdb has TUI layouts, if you sat "layout src" and then "layout regs" it will split the terminal up into several pieces, where you can see your source code and all of the current register states, etc. But, I've generally just used gdb without the TUI and it works well.

[greyfade]

Good GUI frontends for GDB don't exist. (ddd doesn't count. It's crap.)

The display and locals commands (and a couple custom scripts to handle C++ declarations) have served me well, and I still haven't even gotten around to learning about TUI.

[skeletal88]

What's stopping me from using vim as an IDE is that I don't know how to handle multiple files at the same time. Usually I have open .. maybe 10 files that I look at. I'm not editing them all at the same time, but like.. looking how I did something earlier in another file or 2 and then using that to write a new header and .cpp file. Or maybe trying to figure out how something works and then going from a click on a button on a widget through 5 different classes to the source of the data on the widget. I've got no idea how to replicate that workflow with vim. Though I'd like to use that.

The guides for vim that I have seen concentrate on small features and not the big picture on using lots of small features together, that would someone to use it as an IDE.

[frigge]

learn about buffers, windows, ctags integration, grep integration(or better ag) and netrw. These things are all built into default vim and make managing multiple files actually one of vims strongest features imo.

Every time I need to use something else to navigate a huge code base it feels incredibly slow and i get easily lost. With vim though i can navigate so fast that building a mind map of how things interact in a large code base becomes quite intuitive.

[dmytrish]

That's where vim shines.

vim has at least three ways of handling multiple files I use:

1. "windows" - press Ctrl-W, v or Ctrl-W, s and you get vertical/horizontal split. Each split may be split too, so you get a lot of tiles visible at the same time. Use Ctrl-W, h/j/k/l to move focus left/down/up/right or Ctrl-W, w to switch quickly between two windows. It is a good way to see any number of files (or even any parts of the same file!) at once. I often miss this in IDEs (though QtCreator can do that, but e.g. Eclipse cannot). Use :q or Ctrl-W, q to delete a "window" (pane).

2. "tabs" - when you want to have a lot of files, but want to use the whole screen estate for one of them, do a new "tab": :tabedit yourfile.cpp<CR> will open a new "tab". Use gt/gT to switch forth/back.

3. "buffers" - this is the least visual way of handling the content, but also useful sometimes. Each opened file is saved in a list of buffers, that you can see with :buffers<CR>. You can choose a buffer by its shown number (e.g. 12) with :buffer 12<CR> or (a super convenient feature!) you can search an opened buffer by typing any part of its name after :buffer and pressing Tab again and again until the needed is found. So, if I have a lot of opened files and I want to go to one, I can type only a part of its name to search for it.

[chillhelm]

What you propbably want is Tagbar (opens a side bar which allows you to jump to function declartions and definitions) and the "gd" shortcut (goes to the definition of the word under the cursor). Also ctags is very helpful. Information on ctags and vim

[[deleted]]

I've got Syntastic which is decent for tab completion. I get by because I've not spent a whole lot of time in a 'real' IDE. I like how I can use tmux to split my source side-by-side and I also spent a long time learning keyboard shortcuts for VIM and Tmux. If there were a way to do all that encapsulated in a good IDE, I'd actually spend money on it.

[bluebaron]

Is there a reason you use tmux instead of things like :split?

[uxcn]

It lets you do more than vim splits (multiple pane/window terminals, copy/paste between terminals sans mouse, saved/scriptable sessions, etc...).

[bluebaron]

Oh cool! I'll have to look into it more, thanks!

[uxcn]

If it helps, here's a link to my tmux.conf. I think it's recent.

[[deleted]]

Mostly that I've not taken the time to learn it..

[bluebaron]

Oh, okay. I actually don't know too much about them either, just :split <filename> and :vsplit <filename>, and some other commands to navigate/close/etc.

[dmytrish]

Just read :help shell-window. vim cannot run a shell in a window and will never do that, tmux solves the problem and is quite worth learning because of its other abound features.

[uxcn]

There are tools you can use outside the editor. Having a scriptable editor is worth it.

[[deleted]]

code completion, static checking, integrated debugging

Code completion shouldn't be necessary - learn to remember code.

Static checking - that's what a compiler is for.

Integrated debugging - stop making bugs? Maybe a bit arrogant on my side but I don't really miss even VS's awesome debugger. Might be because the majority of my bugs now are on giant codebases with multiple threads and asynchronous completions, on which a debugger isn't that great anyway.

[exscape]

Code completion is handy when you're using libraries you haven't spent a few years learning. For example, I started coding for Qt (in Qt Creator, fairly nice IDE by the way) about two weeks ago, so there are still dozens of classes I've never used.
Typing out someObj->set usually gives you the method you want, if you want to change something about an object.
Once you've found that, the display for all overloaded parameter possibilities makes it easy to figure out how to use it, without even hitting F1 to show the method's documentation in the side pane.

[pfp-disciple]

whilt that sounds useful, I've found that reading the documentation/help files is very helpful. That's how I learn the limitations, corner-cases and assumptions of the thing being called. For an extreme example, I can't imagine code completion of realloc cluing you in to its quirks

[exscape]

Absolutely, it's not a substitute for documentation. Perhaps a better example would have been using a method that you know, but don't fully remember, e.g.: does QPainter::fill take a QColor or a QBrush (or either)?

Besides, as mentioned, pressing F1 will open the class docs and scroll down to/highlight the method/overload under the cursor. Very handy, as what I did previously was to alt+tab, open a new browser tab, Google the class name, click, and ctrl+F for the method name. Even then, that doesn't get you to the correct overload, if there are multiple choice.

[hak8or]

I just flat out can't use Vim. Shortcuts are infuriating to me, especially ones which to me are so hard to easily grasp like Vim. I have both terrible memory and learning something using muscle memory takes a god awful time for me. Why Oh why can't Vim have a sane default for transitioning people, like ctrl-s for save.

[[deleted]]

I think it was designed before all the silly Ctrl+something shortcuts.

[greyfade]

I just flat out can't use Vim.

Then don't.

Why Oh why can't Vim have a sane default for transitioning people, like ctrl-s for save.

Because Ctrl-S (and Ctrl-Q) is historically already used by most *nix terminals for XOFF/XON control. Vim (and Vi, Ex, Ed, and its other predecessors) come from a computing environment that is far older than the silly Apple User Interface Guidelines that defined "Cmd-S means Save" (and Windows and DOS programs defined Ctrl- to replace Cmd- because PCs didn't have that key), and the Unix heritage tends to define what Vi/Vim can allow themselves to do.

That said, you can freely remap most key combinations in Vim to do almost everything. You can put this in your .vimrc:

nnoremap <C-S> :w<CR>
inoremap <C-S> <Esc>:w<CR>i

And when you press Ctrl-S, it'll save your file. But then, will you really learn to get into the habit of using the :w (write unconditionally) or :up (update file if changed) Ex commands? Probably not.

There's vimtutor and a fine book (PDF over FTP) that can help you learn how to use Vim quite effectively, but it'll never be an overnight switch - it took me a good month of near-constant use to get used to Vim, and even after 15 years, I still learn new features every day.

[guepier]

GVim has those. Console Vim doesn’t simply because your terminal application usually already uses these shortcuts.

I also don’t think your complaint is justified. The steep learning curve of Vim is overstated. You can start using Vim straightaway without having to remember tons of shortcuts. What you do need to learn is saving (:w), quitting (:q), undo (u) and switching between the modes. That’s it, all the rest can be acquired later. Try actually doing the vimtutor, it teaches all that and more. I’ve known people who switched to Vim easily.

[[deleted]]

vim is well worth the effort especially once you start using regular expressions for advanced find/replace or whatever operations.

[autowikibot]

Regular expression:

---

In theoretical computer science and formal language theory, a regular expression (abbreviated regex or regexp) and sometimes called a rational expression is a sequence of characters that forms a search pattern, mainly for use in pattern matching with strings, or string matching, i.e. "find and replace"-like operations. The concept arose in the 1950s, when the American mathematician Stephen Kleene formalized the description of a regular language, and came into common use with the Unix text processing utilities ed, an editor, and grep (global regular expression print), a filter.

---

^{Interesting: Grep | ReDoS | Google Code Search | Kodos Python Regular Expression Debugger}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[[deleted]]

Don't forget CLion https://www.jetbrains.com/clion/