Programming on Gnu/Linux: We Need Better Tools

I’m relatively new to programming on Gnu/Linux, so forgive me if I seem impertinent, but what the heck is up with some of the tools available? Specifically, I’m talking about GDB and the lack of C++/STL support.

You know what would be nice? If I could look into the contents of a vector or list from the debugger. Maybe even change a value here or there. But no. GDB, which is past v6.0 now, has no support for such constructs. You’ll have to write very complicated print statements if you want to see the value of just one element. Simple views of STL containers are not possible otherwise. People periodically post to the GDB mailing list about this issue, but no one ever responds to them. There are bugs in the GDB bug database that have been there for years with no one assigned to them.

It seems that no one is even talking about adding such features to GDB. There is no real mention of this problem in their errata list, and so I am not even sure if these kinds of features will ever be introduced by the developers.

I did find gdb_stl_utils, but it didn’t seem to work in my initial tests. When trying to view a vector, I got the following:

Vector Element 0: History has not yet reached $1

Is there a better debugger out there? I found Zero, but it has a strange license agreement at this time. Still, it might be worth a look if it can make debugging C++ programs easier.

Are there open source debuggers out there that would allow me to see the data in STL containers without tediously following almost endless pointers? Am I doomed to use std::cout and std::cerr, requiring changes to the source of my code and any libraries that make use of the STL? Is GDB really the state of the art for Gnu/Linux debuggers?

On the plus side, if it gets frustrating enough, I suppose I could always hire a programmer to make the changes to GDB for me. It worked for Evolution, after all.

3 comments to Programming on Gnu/Linux: We Need Better Tools

  • Ken

    You could always come over to the dark side and use Visual C++ Express. šŸ™‚ Your stuff is cross-platform anyway, right?

  • I suppose, but that would require using Windows as my main development OS, which would be inconvenient, or getting VC++ Express working in Wine, which is something I’d prefer not to do.

    The nice thing about my setup right now is that it is my main OS, the one that I use as my desktop. It’s a one-stop shop for everything. Using Windows for development would basically mean that I need to switch between systems more often than I would like. It also means using Windows, which bothers me enough for the little I use it at my day job. B-)

    I suppose if I start getting into languages like Python I won’t have the problems described above.

  • I donno what the deal with debugging STL is, but even visual studio can sometimes throw a wobbly about it. For a while I was using the great STLPort library (much faster and nicer than normal stl), but its containers did not debug well in VS as all. Now, in 2005, it seems that MS has taken a step backwards, as their own STL doesn’t always debug correctly (and sometimes crashes the program šŸ™ ).

    This is all in stark contrast to debugging something like C# or VB .Net code…but that’s kinda worthless since it requires people to have the runtimes installed.

    So, this for me isn’t a great reason to hop to python or ruby, but it sure makes those languages look a lot nicer.

Twitter: gbgames