I spent the last 3 years doing most of my development work on a Linux box. It is not my choice: our software only runs on Linux, so I have to play along. I am a Windows guy, and working with Linux has made me appreciate how great Windows is.
I *love* using Microsoft's Visual Studio for writing software. When I began developing software in Linux, I tried to find something close to Visual Studio. I started using KDevelop. While it doesn't compare to Visual Studio, I have found it is the closet thing on Linux. It is an Integrated Development Environment (IDE): editor, compiler, linker, and debugger all in one application.
KDevelop is a front end to other tools...GCC for compiling and linking and GDB for debugging.
When you are developing software, sometimes it doesn't work as intended. To track down the problem, there are two schools of thought:
- Use a debugger
- Insert messages in your software that help you get an idea of what is going on (aka "printf debugging")
I've always thought that *real* men use a debugger...if you can't figure out a debugger, you use printf debugging. A debugger is faster than printf debugging if for no other reason, it does not require you to change your software and rebuild it to add a printf message. There are plenty more reasons a debugger is faster, but let's just leave it at this: you will be a more efficient software developer if you know how to use a debugger correctly.
Using KDevelop put me in the former category. I could click on a line and set a breakpoint, run my application, and have it stop at the breakpoint so I could analyze what was going on. This worked well for me until I spent several days trying to track down an issue. I set a breakpoint in my software where I thought the issue was, but that breakpoint was never hit. So I assumed that piece of software was never called, so I looked for the issue else where. After studying the software for several hours, I found that it was impossible for that breakpoint to not get hit. I dropped back to the old school printf debugging technique and guess what...the suspect code was executing, but the debugger was not honoring the breakpoint!
I did some research to find out how it is possible that my breakpoint would not stop my software from running. I thought it might be how the software was built, but nothing I did would make the debugger stop at that breakpoint.
I then found out that I'm not the only one that has run into this issue...it is a BUG in the DEBUGGER!!! How unsettling is that! The tool that is supposed to help you find bugs is actually hiding them from you! Here is the problem report, #1091. This bug was submitted in February of 2003 and it is still not fixed! I thought the open source community was supposed to fix things quicker than commercial software! This is a serious issue and I am shocked more people aren't outraged about it.
So just get another debugger, right? Wrong! GDB is used as the debugger for almost everything! It is used by KDevelop, Eclipse, and (here's the tie-in to Macs) Apple's Xcode. GDB is *not* the debugger for Visual Studio...thank goodness!
I found that all the Linux gurus in my group used printf debugging. Now I know why!
With bug #1091, GDB is terrible for software development. You must use GDB for Linux/Mac software development. Then by the transitive property, Linux/Mac are terrible for software development. If only Visual Studio would work on Linux/Mac!