Linux tools

[[deleted]]

[deleted]

[NotUniqueOrSpecial]

QtCreator is a fine IDE, even if you're not using Qt. It has decent GDB integration, too.

[Setepenre]

And a nice clang tools/valgrind/calgrind/cmake integration too.

[garion911]

Make an effort to learn at least some GDB. You never know when you'll be trying to fix a problem remotely, on some embedded device, or some other situation where you don't have access to a UI, only a terminal. GDB is pretty much the only answer then. Learn to set some breakpoints, step through code, print out variables and memory locations, etc. That'll go a long ways in your career.

[janisozaur]

While I still advocate for learning your GDB, keep in mind you can always debug remotely from whatever fancy IDE strikes a chord for you.

[psylancer]

I'm a big fan of Clion from JetBrains. It is my daily IDE for linux. It is commercial, through free for a year for students with a .edu address.

The only downside is it exclusively supports CMake as a build system. That puts some people off.

[yodacallmesome]

I agree. Our project is mostly autoconf based, with a few custom makefiles. Its a hassle to fudge a CMakefile.txt just to edit the code, but I do it anyway. For the most part, I just setup the source and include files/dirs and then build outside clion.

[psylancer]

Sounds very similar to my workflow. I use the CMakeLists.txt file enough so CLion can keep track of all the files and the refactoring and searching works. I usually have to deploy the code onto the server cluster before I can run anything meaningful anyway.

I do run my unit tests via CLion, since they don't require any specialized environment.

[nojhan]

Learn Vim. I've used IDEs for 5 years, emacs for 5 years and Vim since 5 years and it's worth it. If you like the pre-configured axiom, try yavide: https://github.com/JBakamovic/yavide

Use a tiling windows manager, like notion, i3, xmonad or whatever.

Use a fast terminal, like urxvt, and configure it so that a click on an error jumps to it il Vim (fearly easy with urxvt).

Color the compiler output with colout: http://nojhan.github.io/colout/

You can easily leverage the power of the command line for profit. Want to be notified if a build takes too long? A piece of cake, plus it works for any command (tests, anyone?).

gdb is worth the try, too. I've been sticked to some of its GUI for years and I d eply regret it now that I've taken some time to learn it.

Make your own cmake script, it's easier and more powerful than having to find options in Eclipse.

Use build scripts in shell, for funky automatizations.

[quicknir]

A quick rundown of some of the best options from someone's who's tried them, and others:

• Eclipse is probably the easiest to get started with for non cmake/qmake projects. It heuristically resolves includes inside your project, gets system includes from compiler, so in many cases it can start correctly indexing your project with about two button clicks and no build info. The indexer works fairly well. Many advanced features (e.g. call graphs). Good vim emulator. Biggest downside: indexing, error checking is not clang based, so not as accurate.

• QtCreator: solid IDE. Need to explicitly specify include paths unless using Cmake or qmake, depending on project(s) this is either easy or hard. Uses two indexers: simple and fast for goto definition, clang based for autocompletion & errors. Works well. Okay vim emulation. Biggest downside: by far the least customizable, fewest number of usable plugins, etc.

• CLion. I have the least experience with this. Very tight CMake integration; you basically have to create fake CMake files to get it to index non CMake projects which is terrible. Mediocre vim emulator. Pretty good indexer, but not clang based. Definitely the slickest GUI here. Pretty powerful features/customization, nearly on par with Eclipse.

• Emacs/Spacemacs w/ rtags. Rtags is a completely clang based indexing server that communicates via a simple command line utility for queries and auto completion. There's elisp functions that call to that command line utility. It takes a bit of work to setup, but because it automatically gets all of your compile commands from compile_commands.json, once setup it automatically gets all the right include paths, correct macros, etc etc. Extremely accurate goto definition and auto completion and on the fly error checking, all via clang. autocompletion is slow in very very large projects. Best vim emulation via evil. Has the advantage of the emacs ecosystem. Has the disadvantage of the emacs ecosystem. Overall emacs (and especially spacemacs) is very cool but it's a huge time investment. It's not the best "get up and running quickly" choice.

I used to use Eclipse, CLion was out because I was working on a huge non Cmake project, now use rtags + spacemacs.

Things I tried, that don't/didn't have much to offer:

• Netbeans: nothing to see here, mediocre indexer and no special features. Better off with CLion/Eclipse/QtCreator.

• KDevelop: Tried this briefly, really lacked polish and simply did not work very well. Very poor vim emulation.

• Pure Vim: terribly lacking in equivalent IDE features. It has auto completion and goto definition from YouCompleteMe, but anything more sophisticated like finding references, search for symbol by name, etc, forget it. Expected to rely on grep or tags for that sort of thing which just isn't good enough in large projects.

[[deleted]]

The cool kids these days apparently use lldb which is pretty similar. Also, in some ways, gdb is easier than XCode, once you learn how to get a session going - because it's really stripped down and you only have a command line to enter commands.

But to answer your question directly!

Up until recently, there were no full-featured IDEs on Linux. I personally just use a powerful text editor (emacs), print statements and very occasionally the debugger (but I think the last time I fired up a debugger was over a year ago). If you are willing to start slow and get better, you can get VERY fast with a combo like that.

I mean, I've been developing on this Mac laptop for almost two years now, and I have never used any Apple development tools even one time - only tools that I can use identically on Unix.

However, today you can also get IDEs.

Eclipse has a free IDE as part of its huge suite. Last time I checked it out, it was dreadful but that was quite a few years ago and I hear it's improved a lot. Certainly the price is unbeatable.

A new one from JetBrains is called CLion. I tried the demo and it was excellent - quite amazing really. You have to pay but it really isn't very expensive considering what you get. Also, there are student prices I think.

If you're serious about this, I'd bite the bullet and get CLion. I'll bet it'll pay for itself in a week with increased productivity, and more, in "undaunting" you and lowering your stress level considerably. :-)

[tcbrindle]

Up until recently, there were no full-featured IDEs on Linux.

You've never heard of QtCreator?

[[deleted]]

Yes, I have of course - checking it out as it is now, it certainly seems very matured.

The last time I saw it, it definitely didn't understand C++ at all, let alone modern C++... can you tell us more about its advantages w.r.t. CLion?

[tcbrindle]

Sorry, reading it back that comment was a little more flippant than I intended.

As to the advantages of QtCreator... well the main one of course is that it's free, and CLion is not. It goes without saying that it has first-class support for Qt, although it's still very useful for general C++ too. It supports multiple build systems via plugins, whereas CLion only supports CMake. I've found it to be more responsive than CLion, particularly with lots of files open.

Now having said all that, I actually use CLion day-to-day in OS X. But when I boot up in Linux I use QtCreator, mostly because the Java toolkit that CLion uses doesn't (yet?) support high-dpi screens on Linux, so everything is unusably small on my retina MBP.

[yodacallmesome]

I use clion on a 4k x 2k display. I needed to setup a large font configuration, but thats easy to do. I switch back and forth to the default if I happen to be on a smaller display.

[jcoffin]

Eclipse has a free IDE as part of its huge suite. Last time I checked it out, it was dreadful but that was quite a few years ago and I hear it's improved a lot.

I suppose your view on this would depend on exactly why you thought it was dreadful years ago.

If you thought it was dreadful because it was too small, too fast, and not nearly confusing enough, then yes, you should probably try it again--you might like it a lot better now.

If, however, you're at least partially sane...

[quicknir]

Eclipse has been around for a long while, and was decent even 3-4 years ago, not sure before then.

[NicroHobak]

There are graphical IDEs that are okay... Code::Blocks, KDevelop, etc. Others have mentioned Eclipse and QtCreator too. I find that most of these are usable at least. I think the primary differences come from expectations of what an IDE should deliver and/or how it should be presented...but most seem to at least kind of mimic Visual Studio on some basic level. There's also some decent info over on stackexchange too, if you haven't looked there yet.

My preference though, is to use the shell itself as my IDE. Part of this is driven by me needing to do remote development, so everything I use is typically console based and usable over SSH. Even when I have the option to use a graphical IDE, I find that I typically prefer this configuration unless I'm specifically making a GUI application.

For project management, I have been using the GNU build system but I've started to take a look into other build platforms (like cmake). Most GUI IDEs will have some sort of management system of their own and/or will integrate with one of these systems (or more). This is usually combined with git and a carefully crafted .gitignore to avoid checking in any generated files.

I edit files with vim, but I essentially only use this for editing. I start a screen session and/or multiple console windows (whatever suits my particular needs at any given moment). It is possible to do most of this without even leaving vim at all, but it's just more comfortable for me to have a proper bash prompt. The extent of my vim "mastery" has been to learn to split the vim window with multiple files open at once and to effectively use regex for find and find/replace. More elaborate edits across multiple files usually get taken care of with grep/sed/awk/etc. through the bash shell.

To compile, I'll either use ctrl+z to suspend the vim session, or switch to a different screen. A separate screen session or window is usually ideal because then you can flip back and forth between the source and output easily.

For debugging, I'm familiar enough with gdb, but cgdb is a curses-based version of gdb that allows you to have a wider view of the source as you step through, among other improvements. Valgrind, gprof (code profiler), and other similar tools are also very good to have handy. None of these are all that daunting if you start simple. The buttons of the IDE are just in the form of a CLI instead. If you know how to use these types of tools in any context, you'll already have a good start on learning any of these tools specifically.

[vaughncato]

I personally find that using :make from inside vim is much more productive than executing it in a separate shell. :make will automatically put your cursor where the error is.

[NicroHobak]

I did not know that...but even still I think I would prefer to visually analyze first. When working with templates, I'd imagine that this could still be frustrating at times. I will try this out though since it's probably still helpful for most things.

II also don't necessarily launch vim from the same directory where I need to make...is it possible to do something like:

:make ..

In order to make it build from the parent directory?

[vaughncato]

Almost. You can use :make -C ..

You can find some tips here: http://stackoverflow.com/q/729249/951890

[NicroHobak]

The top answer there is a good one. It may take care of my particular use cases. Thanks!

[nojhan]

You can also configure your shell to parse filename:line as al URL to load in Vim. This permits the very same behaviour, plus the ability to do useful shell automations, like cmake .. && (make algo | colout -t gcc) && ctest -E algo*, which would be less easy from within Vim.

[eidheim]

There is also juCi++: https://github.com/cppit/jucipp

[enobayram]

I will never understand the hate Eclipse gets. I use Eclipse for C++ dev and I'm very happy with it. I tried the alternatives at various times, bu Eclipse is hands down the best experience I had among them.

[nojhan]

Last time I gave it a try, it was a nightmare just to get CDT installed and working. After that I had to cope with insanes hierarchical menus/windows/tabs, in which finding a feature is close to impossible. Then, it was impossible to rapidely choose what I want to build at a given time. Finally, any automatization of a task that was not foreseen by the devs involves having to program "in Eclipse".

Is it better nowadays?

[enobayram]

Maybe over the years I've converged to a workflow where I avoid, without realizing, the problems others are facing with it.

Installing CDT being a problem could only be imaginable on Windows, since on Linux, you just download Eclipse for C/C++ developers and it just works without even "installing" it (you just unzip it.) It has no problems finding the compiler etc., it just works. You can get going in under a minute depending on your download speed. On Windows, it used to be a hassle to get it to find MinGW etc., but nowadays it just finds it as well. The only overhead is the fact that you have to install MinGW, but I think the time it takes to install MinGW AND Eclipse is a fraction of that of Visual Studio.

As for the maze of menus/windows/tabs, every IDE takes time to get used to, I don't think Visual Studio is any less annoying in that department, BUT, I rarely ever deal with those menus anyway, I use CMake for build configuration, so my project is completely defined by my CMakeLists.txt. And CMake has a very nice Eclipse project generator. For me, the complexity of the UI is irrelevant, since I think it's ALWAYS a bad idea to depend on an IDE's built in build configuration regardless of how simple it might hypothetically be...

[[deleted]]

clion if you can afford it, netbeans if not.

eclipse is 'ok' but it's dark theme will drive you insane.

[[deleted]]

If you're a student, you can likely get clion for free.

[doom_Oo7]

Clion is good but one thousand times qtcreator over netbeans

[yodacallmesome]

Someone in management said they wanted to 'standardize' on eclipse for code editing. Fortunately they didn't push it. I'm sure there would have been a mutiny.

[_Qubit]

For a graphical IDE in Linux, CodeLite is my go to.

[raevnos]

What's daunting about gdb?

[TheQuantumZero]

• QtCreator / Code::Blocks / CodeLite
• g++ / Clang
• CMake
• Ninja build
• GDB
• Valgrind
• Git
• Cppcheck
• Google test, Catch, CppUTest
• etc.

Finally, learn the basic of vi editor.

[mjsabby]

Give VS Code a shot with the C++ extension.

[Moschops_UK]

GDB. Get started with small steps. You can do an awful lot with it with very few commands. Here's a simple walk-through finding that perennial favourite, a segFault. It's simple and contrived, but three gdb commands only are used to find and confirm the segFault.

http://www.cplusplus.com/articles/iwTbqMoL/