[TriLUG] Best IDE and version control for C and C++?

Fri Jun 2 23:01:40 EDT 2017

On 06/02/2017 10:28 PM, Charles Fischer wrote:
> I am coming from visual studio 2015 (version 14).  In the past I
> just used vi and the command line build chain.  I am hoping for
> better now.

As much as I dislike admitting it, full-on Visual Studio is a very, very
good IDE (I used to work on it - *on*, not in - in a previous life),
especially after it got the much needed C++ love it so seriously lacked
before.

That being said, the world is much better nowadays: we still have vi but
you don't have to use it.
And for giggles: http://www.commitstrip.com/en/2017/05/29/trapped/  (how
hard is "[esc] :q" really?)

Eclipse lets you create both its own type of projects (and you will need
to open Eclipse to build them, similar to how VS worked before MSBuild
existed. Really, really Eclipse?) or you can use makefile projects.
The former is convenient and you'll get suck(er)ed into using them (like
I did for a couple of projects); the latter are the right way to do it.
You may dislike command line build chains but they do remain the most
powerful, portable, configurable and, frankly, only correct way to do it.

> I would like it to be C/C++ aware, in other words do the indents and
>  bracket alignments (custom, I like brackets on individual lines and
>  case statements to have the case and breaks aligned one tab in from
>  the brackets).

Code::Blocks and Eclipse will give you the ability to do this type of
formatting and customize it to your heart's content. After spending
about an hour setting everything up, you hit Ctrl+Shift+F (or whatever
shortcut you configured) and your entire file will be formatted for you
(or you set it up to do it every time you hit Save).
That's a pain the first time you commit that file to your source code
control because you'll have a big diff (*) but having your IDE apply a
coding style will help you in the long run.

(*) A better way to do it would be to configure your code style, then
apply it to all your files (just the code style) without any other
functional changes, commit that (after a successful build and all tests
passing) and then start actually partying on your code; but you knew
that, right?

> Colors for key words is nice, but not necessary.

I think this is/should be present in any editor (I'm looking at you over
there, notepad... that's right, that's a glare!)
But there's more to color coding than just keywords. Both Eclipse and
C::B come with default code-coloring but let you also configure it just
the way you like it: from soft and dark pastels all the way to lime
green on top of bright red.

> I find myself fighting auto-complete as often as I find it helpful.

Eclipse & Code::Blocks give you the ability to turn it on or off.

> Does not have to tie to unit testing.  I really want it tied to the 
> build tools and debugger.

Eclipse CDT ties in with gdb into something that resembles the way VS
works. Interacting with it in Eclipse is not as 'fluent' as what Visual
Studio offers, but it works well enough. That being said, doing work on
Linux, you /should/ familiarize yourself with gdb itself. Once you get
proficient in it, it will blow your mind and you'll be even more
productive than the point-and-click-and-sometimes-hover visual studio
debugger.
I've played with Code::Blocks in the past but I don't remember its
debugging support.

> Tied to the coverage tool would be nice (insure++ from Parasoft is my
> leading candidate for coverage and memory testing, but that is not
> set in stone).

I tie in (for instance) code coverage through the build system + unit
tests (and integration tests and E2E tests and other tests) and generate
a report through gengcov. But that's just because of how some of my
older projects are set up...

> I doubt that other developers will work on the code
> for the next year or three.

So at least 1 more developer a year from now.... got it! ;)
My recommendation: use Eclipse CDT with makefile projects together with
Mercurial.
One last bit: once you make a choice, be willing to spend a little bit
of time first familiarizing yourself with the IDE before doing any
'real' work or else you may find yourself with a visually appealing yet
functionally/workflow-ey lacking one.

> On Fri, Jun 2, 2017 at 10:06 PM, Thomas Delrue via TriLUG 
> <trilug at trilug.org
>> wrote:
>> 
>> On 06/02/2017 09:21 PM, Ken M via TriLUG wrote:
>>> My default answer for all programming languages is emacs. After 
>>> that there is always code::blocks
>> 
>> Pfff... y'all are a bunch of amateurs: https://xkcd.com/378 (*)
>> 
>> But seriously now though: - What do you need from your IDE? - Do 
>> you want it to be specific to C++ or do you want to be able to use
>>  it as well for (future) components that are written in other 
>> languages? - Do you just want color-coding? - Do you want 
>> auto-complete and how intelligent do you want that to be? - What 
>> about refactoring or built-in integration with unit testing? - Do 
>> you want it to tie in with your build system and/or your code 
>> coverage solution? - Do you want to be able to commit from within 
>> the IDE or are external tools fine? - You're the only dev right 
>> now, but will there be more in the future? - etc... There's a
>> bunch of questions that will guide you towards the solution that is
>> right for you...
>> 
>> From personal experience: I'll go right ahead and recommend
>> Eclipse CDT for C++ work. I've been working in Eclipse for C++
>> development for a couple of years now (set up with a couple of
>> extensions to maximize my productivity). It is/can be a bloated
>> piece of work, but then again, unused RAM is wasted RAM, amirite?
>> 
>> For source code control, I use Mercurial 
>> (https://en.wikipedia.org/wiki/Mercurial) on command line as well 
>> as through TortoiseHg (https://en.wikipedia.org/wiki/TortoiseHg).
>> I like to think of it as the user-friendly version of Git that
>> gets out of my face when I'm doing stuff. I'm sure there is an
>> Eclipse extension for it; I also do know that there is a git
>> extension (called EGit) for Eclipse. The downside of picking
>> Mercurial is that you'll need to jump through a couple of hoops if
>> you want to abuse and negate your nice distributed source code
>> control system into a centralized one by using GitHub (sorry, I got
>> distracted for a moment there, where was I...?) Basically, anything
>> that is a distributed source code control system will work pretty
>> well: git, mercurial, bazaar, ... take your pick, but pick
>> mercurial, seriously though... pick mercurial, you'll thank me
>> later!
>> 
>> If all else fails, you can abandon Linux and install this operating
>> system called Emacs. I hear it comes with a relatively ok editor...
>> ;)
>> 
>> For those recommending VSCode or Atom, it's been a while since I've
>> looked at them but do they have refactoring or auto-complete yet
>> for C++ or are they still mostly/only for building websites/doing
>> javascript? What about proper build integration? Can I create a
>> (C++) project and set specific build options yet? If so, which
>> extensions would I need. I'm not trying to be facetious, just 
>> genuinely curious.
>> 
>> (*) https://en.wikipedia.org/wiki/Editor_wars
>> 
>>>> On Jun 2, 2017, at 9:18 PM, Mike Perry via TriLUG 
>>>> <trilug at trilug.org> wrote:
>>>> 
>>>> NetBeans and Eclipse are decent choices. At work I've been 
>>>> using Atom lately. I tend to bounce around a bit just to see 
>>>> different things.
>>>> 
>>>> Even though it's not open source, I'm a big fan of Visual 
>>>> Studio Code to be honest. It's free and pretty powerful. 
>>>> https://code.visualstudio.com/ It's also available on most 
>>>> flavors of Linux.
>>>> 
>>>> On Fri, Jun 2, 2017 at 8:05 PM, Charles Fischer via TriLUG < 
>>>> trilug at trilug.org> wrote:
>>>> 
>>>>> I have been away from Linux software development for too 
>>>>> long. Much too long.  So what is considered the best open 
>>>>> source IDE and version control system (integrated?) for C
>>>>> and C++ development?
>>>>> 
>>>>> Information about the environment and the software being 
>>>>> developed:  1) I am the only developer.  2) The software
>>>>> will be GPL licensed, not sure which version at this time.
>>>>> 
>>>>> Related question, what open source archival software do 
>>>>> people like?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.trilug.org/pipermail/trilug/attachments/20170602/21e9f15b/attachment.pgp>