Related
can someone be kind enough to direct me to emacs tutorials for large C++ project using gdb as debugger, the project does contain make file.
I did search for emacs tutorials but some are too advanced for beginners and some only target one single file tutorial. I did read the previous posts too but did not find an answer suitable for large projects. Also I am not used to using 'git', one of the answers in previous posts.
Actually, learning Emacs is a thing that just can't be easy. You'll have to learn the basics before you will be able to read "advanced" tutorials.
The first thing you should do is to work through the builtin tutorial (C-h t). It's really good.
Then you should try to familiarize yourself with Emacs configuration basics. The easy way suggested by many users is to get a ready-for-use configuration (such as Emacs Starter Kit) and try to understand it and then tailor to your own needs and preferences. The advantages of using a ready-made configuration kit are:
It's a working code useful for learning the basics of Elisp. This learning path is way faster than reading Elisp manuals and gathering configuration code one small piece at a time.
It demonstrates a lot of useful Emacs features which otherwise might require you long time (sometimes years) to discover.
It offers a framework which you can base on writing your own configuration.
Still you should undoubtedly get rid of whatever parts of configuration you don't need.
Then (or along with the previous step) read some tutorial about using Emacs as a development platform. You can easily find a lot of tutorials via "emacs for [c] development" queries to Google. Here is one of many.
Then install Cedet (Alex Ott has written a great tutorial about it) and start feeling the power.
After that you'll know what to do next.
By the way, there is a great collection of Emacs resources maintained by Bozhidar Batsov.
Start simple. Launch Emacs without any customisations and start editing your source files. The only "tutorial" you'll need to do basic editing is the inbuilt one you'll get by hitting Control H followed by t (Referred to as C-h t in Emacs speak).
Compiling can be done by typing M-x (Alt x) compile and hitting enter. It will prompt you for the compile command which is by default make. Change it to whatever suits you.
Running gdb is done using M-x gdb and hitting enter. The interface is similar to the M-x make.
Don't use things like the Emacs starter kit which makes assumptions on your behalf. While useful as a starting point for newbies, it suppresses curiosity and that's the key to learning Emacs. The above things should be enough for you to start. Once you hit problems and are not satisfied with the ways of doing things, you can search for resources and things. Emacs is not an "IDE" and so you won't have the tight integration which many custom editors have. Don't expect it.
I want to write a C++ application with Qt, but build a prototype first using Python and then gradually replace the Python code with C++.
Is this the right approach, and what tools (bindings, binding generators, IDE) should I use?
Ideally, everything should be available in the Ubuntu repositories so I wouldn't have to worry about incompatible or old versions and have everything set up with a simple aptitude install.
Is there any comprehensive documentation about this process or do I have to learn every single component, and if yes, which ones?
Right now I have multiple choices to make:
Qt Creator, because of the nice auto completion and Qt integration.
Eclipse, as it offers support for both C++ and Python.
Eric (haven't used it yet)
Vim
PySide as it's working with CMake and Boost.Python, so theoretically it will make replacing python code easier.
PyQt as it's more widely used (more support) and is available as a Debian package.
Edit: As I will have to deploy the program to various computers, the C++-solution would require 1-5 files (the program and some library files if I'm linking it statically), using Python I'd have to build PyQt/PySide/SIP/whatever on every platform and explain how to install Python and everything else.
I want to write a C++ application with Qt, but build a prototype first using Python and then gradually replace the Python code with C++. Is this the right approach?
That depends on your goals. Having done both, I'd recommend you stay with Python wherever possible and reasonable. Although it takes a bit of discipline, it's very possible to write extremely large applications in Python. But, as you find hotspots and things that can be better handled in C++, you can certainly port relevant parts to C++.
Is there any comprehensive documentation about this process or do I have to learn every single component, and if yes, which ones?
Here's what I'd recommend for the various pieces:
EDITOR/IDE: Use any editor/IDE you're comfortable with, but I'd highly recommend one that supports refactoring. If you're comfortable with Eclipse, use it. If you want to mainly go the C++ route and you're not too familiar with any editors, you might be better off with QtCreator. Eric is an extremely good Python IDE with support for refactoring, unless you're going to be doing lots of C++, take a look at it. Even better, its source code is an example of good PyQt usage and practices.
PROCESS:
The quick summary:
Write your application in Python using PyQt
When identified as hotspots, convert decoupled Python classes to C++
Create bindings for those classes using SIP
Import the newly defined libraries in Python in place of their Python counterparts
Enjoy the speed boost
General details:
Write the application in Python using PyQt. Be careful to keep a good separation of concerns so that when you need to port pieces to C++ they will be separate from their dependencies. When you finally need to port something to C++, write it in C++/Qt and then create bindings for it using SIP. SIP has a good reference manual on the process, and you have all of PyQt as an example.
DEPLOYMENT:
C++ - For many applications the dependencies are sufficiently simple that it's not too difficult to create an installer using a tool like NullSoft's Installer or InnoSetup.
Python/PyQt - PyQt applications are a bit more difficult to install because of the dependency on Python and its dependence on the presence of the Qt libraries. One person documented his efforts on this post at ARSTechnica. py2exe works pretty well on Windows and should work fine. IME, freeze.py, which comes with the Python source, sometimes has problems determining which shared libraries are truly necessary and will sometimes end up creating a binary whose dependencies aren't present. Py2app can be made to work on Mac OS X.
But worse, however, is the PyQt/Qt licensing. If you are developing a commercial application, you need to have a commercial PyQt (and Qt) license and make sure to prevent the users from easily modifying the source or otherwise writing code against the PyQt/Qt API because of licensing restrictions. Because of that, the PyQt author created a tool called VendorId (although it has a Python license). Within VendorId is a tool called SIB that can be used to create an executable which depends only on the Python interpreter. But, if you're going to go this far, you might want to install a custom Python along with your application.
DISCLAIMER: I haven't used PySide at all, so I'm not sure how it compares to PyQt. Also, note the following warning on their website:
PySide is a work in progress and is not yet suited for application development requiring production-level stability.
But, on a good note, they intend, at least for the initial release to "maintain API compatibility with PyQt." So, aside from the C++ bindings, you could easily switch between the two later.
If you are just learning Qt and want to leverage the speed of prototyping that Python gives you, then I would recommend you make a sample project using PyQt. As you said, there is a debian package, so you are just a simple apt-get away from making your first application.
I personally use gVim as my Python/Qt editor, but you can really use any Python-friendly editor without much trouble. I liked WingIDE and they have auto-complete for Qt but once you sip from the vim kool-aid it's hard to switch.
I would say that PySide is 95%+ compatible with PyQt and the LPGL license is nice, but if you are just trying to prototype your first Qt app, then I don't think there is a real reason to use PySide. Although, I do like the PySide docs better, you can also just use them and replace all the library references with PyQt.
Depending on the complexity of the application you are building, it might be better off to just start from scratch with a C++ version than to try to do a bunch SIP refactoring black magic. Once you have a solid grasp of the Qt framework, you should be able to switch between the C++ and Python bindings pretty effortlessly.
I would draw UI mockups before starting to code prototypes. Here are some benefits:
Quicker than coding prototypes as there is no programming involved
Quickly fill widgets, such as tables and trees, with data
Add descriptions and notes to your screens
Easily integrate mockups into specification documents without having to capture screens
Validate UI design concepts before implementing
There are a lot of tools that can help you do that, but if you are going to use Qt, MockupUI may be a good choice as it renders Qt widgets with native styles for Windows 7,8 or 10 which makes your mockup look more realistic.
For those who are using vim/emacs/terminals,etc (ie, not an IDE proper) what sort of projects are you working on? Are they big? Production? Are these the tools you use at work? Or mostly for smaller things...or big things broken into small things? Sorry...enough questions.
I ask because I'm studying computer science right now, and am super excited about it. I had an internship programming J2ME for a government agency recently and it was Netbeans and eclipse all the way. So I've only had a few "minor-league" years in the business.
In short, what is practical for the CL type tools, versus an IDE such as 'beans and VS. I've got a lot to learn, and the CL tools will probably teach me, versus shielding me like an full on IDE might.
What sort of projects are you working on?
All kind... vim is my main "IDE" anywhere
Are they big?
Yes... My FOSS project CppCMS written almost 100% in vim
Production?
Yes, most of production code (Not FOSS) I write today I use vim.
Are these the tools you use at work?
Yes.
I would explain severak simple things:
vim provides almost all tools IDE does, highlighting, spellcheck, autocomplition, working with multiple buffers, build, context "jumps" (decl, def) and much more
It is extreamly portable, I work with it on Windows, Linux, OpenVMS, Solaris, FreeBSD.
It is very light in comparison to bloated IDE.
There is only one thing I do use IDE today: debugging hard bugs.
Emacs/Vim can be used for any sized projects.
Generally, you won't get to choose the environment, the job you find will have one already picked out for you (unless it's non-Java programming in Unix, in which case use what you want).
I wouldn't sweat the choice, just learn to use which ever editor/IDE is available to its utmost extent.
I use (and have used) Emacs for personal projects, and in two different companies on software projects exceeding 10M lines of production code each.
I use emacs. I would recommend emacs. I have used emacs since before it was emacs: TECO, TV, and the e macro package on the Decsystem-20.
I can use vim if I need to but what you learn is largely what is at hand and you get into.
Yes, learn one or both. And I would say, if the IDE fits, wear it too.
I use vim for everything, I hate IDEs, they're too bloated for me.
I haven't used it for any massive projects (because I haven't written any massive projects), but if I were going to, I would still use vim.
When learning I new language, I believe it's best to not use IDEs at all, and to learn the "proper" way of doing it (like for c++, learning the command line switches and using makefiles).
Twenty years ago all my programming was done in plain text editors, mostly emacs, but technology has improved over the years.
I still do use plain text editors to write code occasionally, but only when it is inconvenient to install an IDE on the machine where I'm writing code. For example, a few times I've stopped by a client site without my laptop and wanted to write a quick program.
This is also an issue with certain embedded systems, where you may want to update the code interactively through a RS232 or USB based command line interface.
Most modern IDEs provide enough acceleration to the code editing process that I will install one whenever I expect to use the computer for development for more than two or three hours.
I use vim for everything from small one-off scripts to 1000+ line production code. It is so versatile that working in any other environment seems constricting. If I'm part of a project that necessitates a standard environment (IDE) then I'll do as much coding as I can in vim and then import into the ide.
I believe everyone should be able to operate effectively in a command-line environment. You can't always be sure that anything except the basic tools will be available on the target machines, you can't be sure that you'll have enough system to pull up a full IDE, and you might actually find the system you're building is too complicated for an IDE.
I've built systems that have consisted of multiple interoperating clients and servers distributed across multiple physical machines. In these efforts, I have used command line tools almost exclusively in the server side. I will use DDD when I can, but I also know the underlying gdb. If the clients are Windows, I'll use the Visual Studio IDE, but if they're UNIX, I'll go with the command line.
Figure out how to work effectively using minimal tools. You'll be a better developer and you'll actually appreciate the integrated tools more, if they're done better.
BTW, I put Emacs in the IDE class. I've got a friend who comes in and fires it up first thing and doesn't leave the environment all day. It's more than an IDE, in fact, since he does mail, surfing, etc. in the thing, or so he tells me.
For large projects with 100+ files, using an IDE is very important. But there are lots of small small things which you need to keep doing all the time while working on even large projects. Firing up the IDE for all of these may not be worthwhile. Having a good command on a powerful editor like Vim or Emacs is something I would consider as an essential skill for any programmer. But an appropriate IDE should also be used to accelerate regular development work as per project needs.
Hmm... Well, look at it this way:
I open code in emacs. I edit it. I use code completion (and I've even played with intellisense emacs)... When I'm ready to compile, I hit CTRL+F7... A key I've bound... It builds in a small popup window... If there are any errors, I can jump to them in the code by hitting f8 (another bound key)... Once it's all building, I hit f5... (this runs a little program I wrote that parses the Makefile and determines the path the executable)... This starts the debugger in a small popup window... I can click on code lines to set break points... etc... I debug... I can "next" through the code with F10... I can "step" through the code with F11 (more key bindings)... When it's all done I hit Shift-F7 to package (.rpm) the project.
So, do I have an IDE? Or am I just using a plain text editor?
1. Yes. 2. Any kind of project.
There is no limit to the size of a system that can be developed in Vim/Emacs/Unix, in fact, there are fewer limits than there are in IDE's. Let's look at a few things I use...
SYSTEM LINES OF CODE
Linux kernel 10,000,000
NetBSD 4,000,000
Ruby 200,000
Those are pretty big systems.
I don't believe any of them were developed with IDE software.
I tend to agree that for learning it is a good idea to understand the basics: the fact that you edit the code, you compile it with a compiler, link it with a linker, debug it with a debugger.
It makes it easier to grasp the concepts. And it makes easier to move from platform to platform.
So, learn vi, make, gdb, some version control system (git, svn).
But for production I would say that getting familiar with the "standard IDE" of the environment is a must (Visual Studio for Windows, XCode for Mac OS, Eclipse for Java, etc.)
No mater what other say, mastering an IDE will increase your productivity.
If you used vi/emacs for 10 years and try Eclipse or Visual Studio for few days, you will say that they are bloated and don't offer anything in exchange. That's BS. The more open minded you are, the better you will be.
I use Emacs to develop commercial software with size of several millions LoC, and massive use of templates, etc. I use CEDET + gnu global as auxiliary packages + yasnippet, etc.
well...I have to say that I'm a vimmer. Using a IDE, I don't to care so many things like when you use editor like vim/emacs. But when you do a bit more, you will find the IDE you use is more hindering than helping in your program developping process. alas...if you insist in using vim/emacs as your editor, you will encounter "a deep learning curve", you will waste so many time even to acchieve so trivial a function in your editor,you will be desperate when you are busy catching up with your timetable if you just pick them up......you have to settle down and start leaning and also playing with editors and a couple of days, you will find you've already achieve more than you can ever expect!
My standard IDE is a flock of xterms running some mix of vim editors, man page documentation, debuggers, log tails, and command lines to execute things, plus an instance of Firefox for pulling up additional docs or (where applicable) testing web-based code. This is what I use for all projects these days, regardless of size, whether personal or professional.
Pretty much the only time I've seen real benefit to using an IDE has been when I've been working on platform-native GUI apps, where they make it so much easier to build forms and wire up their controls. But I haven't done that sort of work in over a decade - the last one I did was in Deplhi, back when Borland still owned it; I think version 4 had just come out, although it might have been 3.
Emacs is a great tool (so is Vim) for programming, and I use them to develop my code for physics research. As added benefit (for me) Emacs handles remote files nicely via Tramp, so that's big boom for me since I very often have to visit remote servers.
With that said, every time I need to write an application with a GUI and within a large framework (like c# with .NET or the android framework) I always find it hard to development with just emacs. The IDEs (Visual Studio, Eclipse) simply have everything including autocomplete and lookup with appropriate content from the framework, and debugging, even though code writing part is always unsatisfactory (I always end up installing some sort of emacs plugin for the IDE, which always fall short of Emacs proper!).
Sometimes it just takes too long to setup an environment in Emacs for those kinds of projects since that is not the default way envisioned by the designers, and having an environment that works out of box is so much easier than banging my head against the wall to find usually obscure information on how to compile/debug those app without using the designated IDE.
We could sum things up by saying that editors like emacs / vi implements some of the functionnalities of IDEs by using CL tools (or the libs behind the CL tools).
Your main issue in using an editor as an IDE would be :
configuring it to have exactly the functionnalities you are happy with in an IDE is not necessarily straigh-forward (I ask for sympathy from anyone who ever tried to configure CEDET ;) ), as opposed to working out-of-the-box with IDEs
the way such functionnalities work in editors is very tied to CL, so you need at least a vague understanding of the CL beforehand.
The advantages are the fact that CL tools are sometimes more ubiquitous than IDEs. Also mastering CL opens the door to scripting your build ("make a build in one command" as opposed to "make a build in one click"), which opens the door to automated nighly builds, continuous integration, etc... all of which are harder to setup if your understanding of the build stops at hitting F6 or whatever.
I do TDD on a daily basis for my C++ development on Solaris10. It has greatly reduced the time I have to spend using my debugger but sometime this is the only option.
DBX is pretty powerful but not that user friendly. Note that I'm talking about console DBX not the SunStudio GUI for DBX).
What are the best productivity tips you can give for dbx C++ debugging?
PS. Changing debugger is not an option.
I have bookmarked a few sites related to dbx. Here they are, in no particular order in case they might be useful to you:
Why Can't dbx Find My Function?
Online Help for the Dbx Debugger
Sun Studio: debugging a multi-threaded application w/ dbx
gdb vs. dbx: commands mapping and feature comparison
Importing debug information into dbx
command line dbx : See more source
Sun Studio C++ - Your .dbxrc (NB: adapt the integer type used to cast pointers according to your pointer size)
Sun Studio: Investigating memory leaks with dbx
Sun Studio: Gathering memory allocations/leaks data, from a running process
EDIT on 2012 july 19th: I've tried to fix several link since Chris Quenelle's blog has moved. Some articles can still be accessed thanks to the wayback machine.
One of the powerful features of dbx is the built in ksh. You can write shell functions that are as complex as you might want to print customized views of data structures, or follow pointers in a specific route. The shell is an old variation of pdksh, so it's not the nicest for programming, but it's much better than not having any built-in language to use. There is also extensive help available from the command line. One trick for searching the help is to use "vi $helpfile" from within the dbx command shell. Tha tedits the raw helpfile data in one large file. You can see some examples of shell functions in the dbxrc file that ships with dbx and is loaded by default. You can see a more sophisticated example by looking at the libumem integration module. You can find it here:
http://quenelle.org/sun%20tech/2007/using-dbx-and-libumem.html
I too have to use dbx at work and understand your frustrations!
A few tips I have discovered which make my life a little easier:
Using the built commands system like this:
when stop { print whatever ; }
Obviously doesn't work when whatever is out of scope, but I find it useful enough. I have yet to have much joy with the 'trace' facility, YMMV.
Making your own .dbxrc file makes life much easier, as does the "pathmap" feature.
Finally, this is only obvious if you know it already, but try Sun's manual.
It isn't particularly well written, but still an essential read.
Thanks to Luc Hermitte! Here is an updated version of his links and a few others.
Why Can't dbx Find My Function?
Sun Studio: debugging a multi-threaded application w/ dbx
Importing debug information into dbx
command line dbx : See more source
Sun Studio: Investigating memory leaks with dbx
Sun Studio: Gathering memory allocations/leaks data, from a running process
Memory Leak Checking with libumem (if you are using dbx you might want to know about libumem)
Using dbx with libumem (substantial dbx script example)
How to use counts with breakpoints
Adding automatic pretty-printers to dbx
Oracle: Getting Started with dbx 12.3
Oracle: dbx Manual 12.2
Additional tips:
dbx has a ksh shell built in, so you can build powerful customized functions.
You can get simple tracing with something like:
when at foo.cc:35 { print varname; }
view all of the online help using: vi $helpfile
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Briefly: Does anyone know of a GUI for gdb that brings it on par or close to the feature set you get in the more recent version of Visual C++?
In detail: As someone who has spent a lot of time programming in Windows, one of the larger stumbling blocks I've found whenever I have to code C++ in Linux is that debugging anything using commandline gdb takes me several times longer than it does in Visual Studio, and it does not seem to be getting better with practice. Some things are just easier or faster to express graphically.
Specifically, I'm looking for a GUI that:
Handles all the basics like stepping over & into code, watch variables and breakpoints
Understands and can display the contents of complex & nested C++ data types
Doesn't get confused by and preferably can intelligently step through templated code and data structures while displaying relevant information such as the parameter types
Can handle threaded applications and switch between different threads to step through or view the state of
Can handle attaching to an already-started process or reading a core dump, in addition to starting the program up in gdb
If such a program does not exist, then I'd like to hear about experiences people have had with programs that meet at least some of the bullet points.
Does anyone have any recommendations?
Edit:
Listing out the possibilities is great, and I'll take what I can get, but it would be even more helpful if you could include in your responses:
(a) Whether or not you've actually used this GUI and if so, what positive/negative feedback you have about it.
(b) If you know, which of the above-mentioned features are/aren't supported
Lists are easy to come by, sites like this are great because you can get an idea of people's personal experiences with applications.
Eclipse CDT will provide an experience comparable to using Visual Studio. I use Eclipse CDT on a daily basis for writing code and debugging local and remote processes.
If you're not familiar with using an Eclipse based IDE, the GUI will take a little getting used to. However, once you get to understand the GUI ideas that are unique to Eclipse (e.g. a perspective), using the tool becomes a nice experience.
The CDT tooling provides a decent C/C++ indexer that allows you to quickly find references to methods in your code base. It also provides a nice macro expansion tool and limited refactoring support.
With regards to support for debugging, CDT is able to do everything in your list with the exception of reading a core dump (it may support this, but I have never tried to use this feature). Also, my experience with debugging code using templates is limited, so I'm not sure what kind of experience CDT will provide in this regard.
For more information about debugging using Eclipse CDT, you may want to check out these guides:
Interfacing with the CDT debugger, Part 2: Accessing gdb with the Eclipse CDT and MI
CDT Debug Tutorial
gdb -tui works okay if you want something GUI-ish, but still character based.
You won't find anything overlaying GDB which can compete with the raw power of the Visual Studio debugger. It's just too powerful, and it's just too well integrated inside the IDE.
For a Linux alternative, try DDD if free software is your thing.
Check out Nemiver C/C++ Debugger. It is easy to install in Ubuntu (Developer Tools/Debugging).
Update: New link.
Qt Creator seems like good stuff. A colleague showed me one way set it up for debugging:
Create a new project, "Import of Makefile-based Project".
Point it to your root project folder (it will index sources under it, and it is impressively fast).
Go to project settings and add a run configuration, then specify the executable you want to debug, and its arguments.
Qt Creator seems to insist on building your project before debugging it. If you don't want that, or don't use make, just go to projects -> build (Left panel), then, on the right panel in "Build Steps", remove all the steps, including the step by default when you created the project.
That may seem like a bit much work for debugging an app I had already compiled, but it is worth it. The debugger shows threads, stacks and local variables in a similar way to Visual Studio and even uses many of the same keyboard shortcuts. It seems to handle templates well, at least std::string and std::map. Attaching to existing processes and core dumps seems to be supported, though I haven't tested it yet.
Keep in mind that I used it for less than and hour now, but I'm impressed so far.
I loathe the idea of Windows development, but the VC++ debugger is among the best I've seen. I haven't found a GUI front end that comes close to the VC one.
GDB is awesome once you really get used to it. Use it in anger enough and you'll become very proficient. I can whiz around a program doing all the things you listed without much effort anymore. It did take a month or so of suffering over a SSH link to a remote server before I was proficient. I'd never go back though.
DDD is really powerful but it was quite buggy. I found it froze up quite often when it got messages from GDB that it didn't grok. It's good because it has a gdb interface window so you can see what's going on and also interact with gdb directly. DDD can't be used on a remote X session in my environment (a real problem, since I'm sitting at a thin client when I do Unix dev) for some reason so it's out for me.
KDevelop followed typical KDE style and exposed EVERYTHING to the user. I also never had any luck debugging non KDevelop programs in KDevelop.
The Gnat Programming Studio (GPS) is actually quite a good front-end to GDB. It doesn't just manage Ada projects, so it's worth trying out if you are in need of a debugger.
You could use Eclipse, but it's pretty heavy weight and a lot of seasoned Unix people I've worked with (me included) don't care much for its interface, which won't just STFU and get out of your way. Eclipse also seems to take up a lot of space and run like a dog.
I use cgdb, simple and usefull
I use DDD a lot, and it's pretty powerful once you learn to use it. One thing I would say is don't use it over X over the WAN because it seems to do a lot of unnecessary screen updates.
Also, if you're not mated to GDB and don't mind ponying up a little cash, then I would try TotalView. It has a bit of a steep learning curve (it could definitely be more intuitive), but it's the best C++ debugger I've ever used on any platform and can be extended to introspect your objects in custom ways (thus allowing you to view an STL list as an actual list of objects, and not a bunch of confusing internal data members, etc.)
I used KDbg (only works under KDE).
Check out the Eclipse CDT project. It is a plugin for Eclipse geared towards C/C++ development and includes a fairly feature rich debugging perspective (that behind the scenes uses GDB). It is available on a wide variety of platforms.
DDD is the GNU frontend for gdb: http://www.gnu.org/software/ddd/
Similar comfortable to the eclipse gdb frontend is the emacs frontend, tightly tied to the emacs IDE. If you already work with emacs, you will like it:
GDB Emacs Frontend
Qt Creator-on-Linux is certainly on par with Visual Studio-on-Windows for C++ nowadays. I'd even say better on the debugger side.
I've tried a couple of different guis for gdb and have found DDD to be the better of them.
And while I can't comment on other, non-gdb offerings for linux I've used a number of other debuggers on other platforms.
gdb does the majority of the things that you have in your wish list. DDD puts a nicer front on them. For example thread switching is made simpler. Setting breakpoints is as simple as you would expect.
You also get a cli window in case there is something obscure that you want to do.
The one feature of DDD that stands out above any other debugger that I've used is the data "graphing". This allows you to display and arrange structures, objects and memory as draggable boxes. Double clicking a pointer will open up the dereferenced data with visual links back to the parent.
There's one IDE that is missing in this list and which is very efficient (I've used it in many C/C++ projects without any issues): Netbeans.
What can be stepped through is going to be limited by the debugging information that g++ produces, to a large extent. Emacs provides an interface to gdb that lets you control it via the toolbars/menus and display data in separate windows, as well as type gdb commands directly. Eclipse's CDT provides similar tools. I've heard of Anjuta and Code::Blocks but never used them.
As someone familiar with Visual Studio, I've looked at several open source IDE's to replace it, and KDevelop comes the closest IMO to being something that a Visual C++ person can just sit down and start using. When you run the project in debugging mode, it uses gdb but kdevelop pretty much handles the whole thing so that you don't have to know it's gdb; you're just single stepping or assigning watches to variables.
It still isn't as good as the Visual Studio Debugger, unfortunately.
Have you ever taken a look at DS-5 debugger?
There is a paid version which includes a lot of helpful features, but you can also use Community Edition for free (which is also quite useful especially for embedded systems).
I have a positive experience with this tool when debugging Android applications on real device using eclipse.
You don't mention whether you are using Windows or UNIX.
On UNIX systems, KDevelop is good but I use KDbg because it is easy to use and will also work with apps not developed in KDevelop.
Eclipse is good on both platforms.
On Windows, there is a great package called Wascana Desktop Developer which is Eclipse CDT and MinGW all packaged up and preconfigured nicely for the minimum of pain. Its the best thing I've found for developing GNU code on Windows.
I have used all these debuggers and none of them are as good as MS Dev Studio. Eclipse/Wascana is probably the closest but it does have limitations like you cannot step into DLLs and it doesn't do as good a job at examining variables.
The Code:Blocks C++ IDE has a graphical wrapper, with a few of the features you want, but nothing like the power of VS.
VisualGDB is another Visual Studio plugin to develop and debug applications on linux and embedded platforms.
KDevelop works pretty well.
Have you tried gdb -w with cygwin gdb.
It is supossed to have a windows interface which works fairly well.
The only problem I found is that on my present machine it didn't run that way until after I installed ddd. I suspect that it requires tcltk which was installed when I installed ddd.
Latest version of Geany supports it (only on Linux, though)
If you are looking for gdb under Visual Studio, then check WinGDB.
In the last 15 months I use insight (came with FC6). It is not great, it is written in Tcl/Tk, but it is simple and useful. DDD is of similar quality / utility, but somewhat harder to use (various GUI gotchas and omissions). I also tried to integrate gdb with my IDE, SlickEdit. It worked OK (I played some 4 hours with it), but I did not like the GUI context switches. I like my IDE to remain unchanged while I am debugging; on Windows I use SlickEdit for IDE and Visual Studio Debugger for debugging. So from the 3: Insight, DDD and SlickEdit, Insight is my 1st choice, I use it >95% of the time, command-line gdb and DDD make up the other 5%. If I get the chance, I will eval Eclipse at some point, my work PC does not seem to have enough RAM (1GB only) to run Eclipse reasonably well.
I have also heard a lot of praise for TotalView, including 1st hand during a job interview. I obtained an eval for our company in late 2008, but in the end we did not proceed as gdb was good enough for our needs; and it is free and ubiquitous.
Use www.zero-bugs.com/
Zero debugger, it requires C++0x support from gcc
I was searching for a debugger to step through a running programm. Say: Attach. The programm was build with eclipse, but because of maybe some multithreadding obstrucles, no sourcefiles where fond. What ever.
I got very compfortable with NetBeans.
[debug] from menu -> Attach Deugger...
as process chose the one to debug
as project [new project]
Now the window disappars and you see nothing. detach from the process. The Read Square "Stop" helps.
import source from the project as e.g. folder. ".../MyProject/src
Now it appears in your project, and you can set breakpoints.
again ttach debugger
chose the process to debug.
debugger should stop if programm reaches next breakpoint.
Going to [window] -> [Debugging] -> Will your window make compfortable.