DescentBB

Hey guys,

I'm moving to a new workplace next week, and am just wondering: What do you guys use for the dev environment when coding on/for some flavor of Linux?

The reason I ask is that I've been doing my work (C++ in mostly Windows apps, various other things on occasion) primarily in various flavors of Visual Studio for the last several years, and my new workplace will be much more Linux-oriented. I could just go back to a good text editor (e.g. vi), and that would be fine... but I've grown rather fond of having a nice IDE with lots of handy tools (things like VisualAssist, for example). There are a number of IDEs out there, though, so I'd appreciate any suggestions from you guys.

I believe that Eclipse is the most *common* IDE for C/C++ development on Linux. I've personally only used Eclipse for Java development, which it's great for, but for C, I can't personally speak to it, as I'm an old vim curmudgeon. Eclipse's refactoring tools for Java are top-notch, but I don't know where they sit with C/C++. It probably comes down to how much macro/template use/abuse there is in the code base.

If you don't know already, you may want to wait to find out what your coworkers will be using. If they all use or recommend the same development environment, then that's certainly the path of least resistance.

I asked the devs I'll be working with about it, and they said everyone uses whatever they're comfortable with... thus my question, as what I'm "comfortable with" is VS. I've heard Eclipse recommended in a couple of places, so I may start with that for now, and adjust as necessary.

Thanks, Jeff.

Update:

It really is "whatever you're comfortable with" around here, mostly since all the building/testing happens on build servers and/or remote machines. So I'm using a combination of Putty for ssh (building/testing), WinSCP for file transfers, and doing most of my coding locally on a Win7 work machine with VS 2010 (plus a couple of my fave add-ons).

The one thing I'm having to get used to the most is debugging via gdb. It's clearly powerful, but it's a learning curve.

I prefer vim...but I'm just weird like that.

gdb supports remote debugging, but probably nothing you're used to using would support connecting to that.

If you prefer something graphical, you might want to look into ddd, which is a graphical wrapper around gdb, but again I can't personally speak to if it's good or not, as I've always just used gdb.

Yeah, I've heard about ddd, and as far as I know there's no support for remote-debugging on the machines; so for now straight gdb is fine. I'm starting to get more familiar with navigating around in it anyway.

As far as coding environment, I'll "vi" it if I'm making a small/quick change, but it's no substitute for a nice IDE with handy tools for the bigger stuff.

When people say vi/vim, they typically don't mean the text editor in isolation, but it along with the rest of the Unix toolchain, including make/find/grep/sed/diff/patch/svn/etc., which together make up the coding environment.

My coding experience during my classes in college was (for better or worse) kind of the opposite: all of our professors seemed to be real old-school types, so I learned C/C++ by using emacs in a Unix shell. The sad thing is, the one time I tried to use Visual Studio, I had no freakin' clue how to even compile the code.

This thread has piqued my interest on the matter, too.

I'm considering giving ninja a shot for my python development. Anyone have any thoughts on it?

My brother uses EMACS for C stuff. Something about break points and having split screens in a terminal. /2cents

Does gdb have a way to break into the debugger on demand (Iike cdb/ntsd's Ctrl+C I think it was)? That was the one thing I found a little annoying when trying to get a stack trace for a problem in Rebirth a while back.

Yes, it does.

If gdb is attached, then by default it will catch and break on signals, including SIGINT (ctrl-c). If you're debugging a gui program, you need to hit ctrl-c in the terminal to deliver the signal (or kill -s SIGINT <pid>, etc.). If you're talking about Windows, the instructions may be a little different, but I'd imagine the principle is the same.

P.S. speaking of debuggers, play around with valgrind's memcheck when you get a chance. It's your all-purpose dynamic memory error detector, including uses of uninitialized memory, uses of freed memory, writing outside a heap allocation, leaks, and so on. When I get a crash, it's usually the first thing I do.

One of the guys here was just showing me that the other day. Very cool.