Suitability of Visual Studio 11 Developer Preview for development - c++

I recently downloaded the Visual Studio 11 Developer Preview, and it looks awesome. I read the fine print on the download page, and it says:
Visual Studio 11 Developer Preview is prerelease software and should not be used in production scenarios.
I would be using only the C++ compiler/IDE of VS11, so does anyone know what bugs there are that would prevent me for using VS11 in a production scenario? I really want to start using it and I don't know if it's the C++ part that's not finished, or if it's just some Team Foundation Somethingorother that has nothing to do with me that's not fit for the field.

The licence prohibits it. The WinDP and the associated vNext tools are free- Microsoft would obviously want you to pay. When you download the tools, you agree to the licence terms, which includes not using it in production.
Another obvious thing is that the C++ Intellisense is more than a tad buggy.

There is still work to be done before I would want to use the preview tools all day. The Metro stuff (C++/CX) especially is riddled with red-wigglies that claim something is wrong, but when you press F7 the solution builds without errors and runs fine. If you're using the Ultimate version, you may not find that as often, but I think you will find it. As for whether the compiler currently generates code that is incorrect, everyone hopes that it emits correct code, but of course the WHOLE POINT of the dev preview is to find out whether it does or not. So nobody can answer you. Spending some time on Connect looking at bugs others have submitted might give you a feel for whether your areas have a lot of bug reports against them. An absence of reports is ambiguous, of course -- maybe your areas are rock solid, maybe no-one on Connect is exercising them.

Related

How to prevent Visual Studio 2015 Update 2 to add telemetry_main_invoke_trigger?

A simple C++ console app
int main()
{
return 0;
}
compiled in Visual Studio 2015 Update 2 adds a call to telemetry_main_invoke_trigger to both Debug and Release binaries.
How can I prevent this?
According to Microsoft’s Steve Carroll (Development Manager for the Visual C++ team), you can remove telemetry calls by adding notelemetry.obj to the command options of the linker:
Steve Carroll explained that this will be removed in the upcoming Update 3:
Our intent was benign – our desire was to build a framework that will
help investigate performance problems and improve the quality of our
optimizer should we get any reports of slowdowns or endemic perf
problems in the field. We apologize for raising the suspicion levels
even further by not including the CRT source, this was just an
oversight on our part. Despite that, some of you already investigated
how this mechanism works in nice detail. As you have already called
out, what the code does is trigger an ETW event which, when it’s
turned on, will emit timestamps and module loads events. The event
data can only be interpreted if a customer gives us symbol information
(i.e. PDBs) so this data is only applicable to customers that are
actively seeking help from us and are willing to share these PDBs as
part of their investigation. We haven’t actually gone through this
full exercise with any customers to date though, and we are so far
relying on our established approaches to investigate and address
potential problems instead. We plan to remove these events in Update
3. In the meantime, to remove this dependency in Update 2, you should add notelemetry.obj to your linker command line.

Is Embarcadero C++ Builder a good choice as an IDE? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As we are (me and people I work with) more and more frustrated while working with C++ projects 250 000+ LOC in VS2010 sp1 (the slowness of this IDE is just unbelievable), in my company we were talking about migrating our code to some different IDE. We did some research, and a strong candidate seems to be Embarcadero C++ builder 2011 XE. Any thoughts on it? Is it any good? How does it compares to VS2010 ultimate?
I've been using C++ Builder since 1.0 and I hate it with a passion. You would think after all these years, simple little annoyances would be fixed by now but they are not. Here is a list of issues I have with C++ Builder IDE.
Your layout or personality never is maintained. You create one, save it and it only applies to certain things. For example the debugger window will not maintain its position nor will the message window. If you detach the project explorer it will sometimes dissappear. Most of the time reloading your personality doesn't fix this either. You are stuck dragging your windows back into place.
The debugger will sometimes work and sometimes not work. In a debug build if you set a break point and begin stepping through code, you can hover over a variable to inspect it. Sometimes this works and sometimes it doesn't work on the exact same variable. Crazy!
Eclipse looks for code mistakes like if you forget to put a semi-colon at the end of your statement, it puts a little ? mark in the margin. C++ Builder doesn't do anything like this. It gives you a cryptic compile time error message.
Recent versions of C++ Builder use a makefile similar to VS; it's an XML mess. Eclipse works with CMake and Makefiles. I've read in places that the CMake maintainers are looking for a C++Builder generator but last I checked this doesn't exist. I do embedded and cross compiling so sometimes my C++ Builder code is copied to my embedded development environment or shared with it and I wind up maintaining two build environments.
Not really an IDE but C++Builder does not take advantage of multiple CPUs to compile code. There is, however, a 3rd party tool you can spend more money on to get this. It's called TwineCompile (http://www.jomitech.com/twine.php). With Eclipse, they call out to whatever compiler you're using (gcc, etc...) and those compilers and make support -j option.
C++Builder comes with a limited version of AQTime which is a dynamic code profiler. Spend more and you get the more advanced version. Eclipse supports many dynamic and static code analysis (which also cost $$) but at least the plugins are there. We use Klockworx.
C++ Builder has no support, that I'm aware of, for external source control like GIT. Eclipse does. C++ Builder comes with subversion, I think, built-in. If it supports GIT, I could never get it to work. It tells me it doesn't understand the URL scheme when I give it a git path.
Certain template code I write causes the compiler to segfault and have to completely restart the IDE. This is nuts to me. You have a compiler that is 10+ years old and it's still segfaulting. I have a piece of C++ template code that when I take it to my work computer running exact same version of C++ Builder, it compiles OK, but on my home machine it segfaults. I'm absolutely sure there are no adverse factors at play like viruses, etc...
While compiling a large project that may take a long time, you are unable to browse code with the IDE. Sometimes you may see a compiler warning scroll by and you have to either wait for the compile job to complete to inspect the mentioned line or use an alternate means to open the file.
C++ Builder IDE has a concept of a Project Group with sub projects that are more/less self contained. The Project Group has no concept of a project group include/link path like the sub-projects have. Sub-projects have a base, debug, release paths where debug and release can inherit or block from the base but you don't have this at the project group level. The IDE has global settings which can be inherited but it's for everything you do in the IDE. So there is no way to modify for a given project group, just the include/linker paths for a set of sub-projects. I just think they could have done a better job with this.
C++ Builder's Build output is not color coded to, for example, show errors in red and warnings in some other color. Everything is black and white. VC and Eclipse color code and give option to change colors for various warnings and errors. The output tab in C++ Builder is same way. On big projects, it's very difficult to investigate compiler warnings with the other noise. In C++ Builder's IDE you can select level of warnings but this only affects output in the Output tab and you still get other stupid noise like letting me know its deleting linker state files "CleanLinkerStateFiles."
Unless you're doing Windows desktop GUI development, stay away from Embarcadero/C++ Builder. I started using C++ Builder version 1 back in the Borland days and have a few large projects that are heavily invested in the VCL so I'm stuck with it for those projects but all my new projects, I've been using Eclipse.
On a positive note about C++ Builder, the VCL is quite nice. It's not multi-threaded but it's nice for creating a desktop GUI app really quick. I think it's much faster to get a C++ based GUI app up in CBuilder than it is in VS. And there appears to be a ton of free and paid GUI components for CBuilder; again with a C++ focus. I know C# + VS has a wealth of GUI controls.
UPDATE:
I just ran into a problem today that is same as the one mentioned in this forum:
http://qc.embarcadero.com/wc/qcmain.aspx?d=57631
[ILINK32 Warning] Warning: Error detected (ILI4536)
Make up your mind. Is it a warning or a god dam error?
Scroll all the way to the end where you find individuals modifying ILINK32.EXE to get it working again. As of this morning, our builds stop working. We're dead in the water as we scramble to understand and find out what to do about this.
Is this the kind of compiler/IDE you want to depend on? Again, this product has been around for more than a decade and it still has issues like this. I find this completely unacceptable. Crap product from a company that doesn't give a shit.
Not actually an answer, but I'll just leave it here:
It costs money (yes, VS too, but you already own that, don't you?)
It will be not too easy to migrate a big enough project to new IDE (and compiler), not to say about the people you work with and their habits (I would just quit probably).
There's a new compiler too, with its brand bugs and caveats to learn about. And it's much less widely used than VC++. However, it's based on Clang, which should support standards better than VC++, and be easier to port existing C++ code to.
The difficulty of migrating hugely depends on the nature of your project (is it GUI based, how deeply does it rely on MS VC++ being the compiler?)
There is nothing positive about Embarcadero XE, neither their aging IDE neither their aging compiler. Only use it if you're bound to it (legacy software) or if you want to do Delphi.
For C++, do yourself a favor and join 21st century : stick with something more powerful, versatile and modern such as VC++ or Qt.
This question is really a matter of personal opinion.
I personally HATE Visual Studio with a passion, I avoid it like the plague. My exposure to Eclipse has been limited to Java, but even then I've had a hard time working with it.
I have been using C++Builder for 15 years, since v3.0 all the way up to the latest XE6. Yes, it has quirks and limitations, but I still find it the easiest IDE for me to work with and be productive with, once you know how to work with (or around) them. Maybe my experience with it is hindering my ability to work with other IDEs, but so be it. I still prefer C++Builder over any other. But I only use it for Windows development (the VCL is very mature and robust), I don't do cross-platform development with it yet (FireMonkey still has a ways to go to evolve and mature). And I do use plenty of open-source projects with it. Yes, sometimes I have to tweak their projects and/or code to make them compile, but that it usually a one-time deal and then they work fine.
I'd suggest Eclipse.
As an IDE, it takes a little while to get used too, but it is well
worth the effort.
It's available for Mac OS, Linux and Windows.
You need to have Java installed on your computer, but that's
really a non - issue.
It supports Cygwin, MinGW, and the MicrosoftVisual C++ toolchains. The build in CDT Builder is pretty good too.
You can use it to develop for languages other than C++ (Java , JavaScript, PHP ..)
You can extend it's functionality by installing plugins
IT'S FREE!
Did I mention that it has a built in Web Browser ? Really useful for referring to online documentation, while coding.
1.
We have a solution over 1M LOC and VS2010 handles it ok. We especially like /MP switch for compiling on all available CPU cores.
You did not specify your hardware. If you don't yet run on at least i7-2600 + fast SSD, I suggest trying hardware upgrade first.
2.
I used to use Borland tools a lot in the past. Delphi was rather stable; C++ Builder was much more buggy. Couple of years ago I helped to upgrade old Delphi projects to newer Delphi IDE with some service packs installed. And it had bugs even in the basic File IO APIs which have worked since Turbo Pascal. We had to downgrade to a previous version. I expect that quality of C++ Builder won't be much better than of VS2010.
3.
You did not specify what exactly is slow. You may want to convert some projects into components compiled separately. Also make sure you use PCH.
Also it worth investigating if you abuse C++ inclusion model by including a lot of unneeded header files in each and every unit. If, after preprocessing, Intellisense and compiler have to deal with huge amount of code, no IDE can help.
I have not used Visual Studio 2010 Ultimate for C++, rather C# and C# web services development. That being said, as a test between VS 2010 Ultimate and C++Builder XE, I have created a simple VS C++ Windows Forms application to click a button and show "Hello World" through an event handler. Getting the button onto the VS Window Designer is okay, as long as you remember to access View | Toolbox. If not, it will take some time to track down where the visual components are hanging out.
For reasons that do not make any language sense, the button click event handler has a signature that looks like:
System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {
}
and it goes to the header file as one would expect. The ^ symbol makes little sense. Does using it tie into the CLI/CLR better? I expected a * to indicate a pointer.
After using the default Form1 (only header file created) and subsequently adding a new windows form, I finally obtained the respective cpp file. Maybe the C++ Windows Form Wizard has a bug. Who knows? Anyhow, when adding the button click event by double clicking the button in the designer, the cpp does not obtain the method in either cpp form I tested. Maybe this is normal, I do not know. The end result of this is that after trying to use the MessageBox function within the cpp, it only caused compilation errors. I am sure there is yet another header file that has to be in the include path. I spent no time tracking this down. Trying to set a label component text property caused compilation errors too. About 20 minutes later, I went to C++Builder XE3 in frustration.
In C++Builder, I have tested VCL Forms, FireMonkey Desktop, and FireMonkey Metropolis application creation from the project wizard. Sure enough, I have three different applications saying, "Hello World," in about three minutes total, all calling C++Builder's built in global shortcut function called ShowMessage("insert message here"). The timing could have been slightly different as I did not time it with a stop watch. It took longer to save files with meaningful names than the code itself: one line of typing in the respective click event body in each cpp (not the header).
The other main daily use gotcha with VS, for those of us who love the Brief key map, is that VS is highly challenging to configure into Brief. When doing heavy development in C#, I use C++Builder's editor in Brief mode, saving files as often as I want. VS does correctly detect file updates as you click back to the VS IDE.
On the slowness mentioned by the OP above, I suggest also looking very closely at the hardware platform relative to running Visual Studio. I have noticed that if the .Net framework is out of date, VS will be slow within the IDE. It does not seem to matter which language the project is in either. I use Visual Studio 2010 Ultimate on Parallels with Windows XP Pro, with 2 virtual cores. Generally, VS responds normally within the IDE. While using it, I am NOT thinking, "VS is soooo slow."
Regarding migrating a quarter million lines to C++Builder from VS, I am not sure whether VS event handlers will convert by some wizard or other migration tool. The ^ symbol, if consistently used in all event handlers, may not be a big deal for a regular expression conversion that is custom written. If the project is very thin on the user interface layer and heavy in business rules and data, converting to C++Builder should be relatively easy. I would expect some new coding for the new user interface click events passing the user interaction into the other layers. For prototyping, using data aware components are likely your best bet. In normal application running, expect to have the business rules layer use the STL and built in C++Builder data structures (even the AnsiString c_str() method) to interact with non data aware components. The performance and user experience will likely improve.
Start Edit
A big knock on C++Builder XE3 (note this is two releases behind the current one of five) is that the 64-bit Windows support is only for console applications. The knock is more from not being frequently broadcast on how to use the Add Platform sub-menu that appears when right clicking the mouse over the Target Platforms choice in the Project tree view. This quick method to add more platforms to a project after it may first be targeting 32-bit Windows is virtually painless. A new sub-dialog appears after clicking the sole sub-menu choice and a drop down box appears to select the new operating system and respective 32-bit or 64-bit versions. In my opinion, Embarcadero is not demonstrating often enough how simple it is to add other target platforms. So, to ease all developer's pain if this is not known in advance, I have found three web pages on the Embarcadero site. The first one has pretty pictures of creating a FireMonkey desktop application. Step 5 has the screen capture of the Target Platforms | Add Platform sub-menu choice for adding the Mac OS X platform. It is here titled Creating Your First FireMonkey Application for Desktop Platforms (C++): http://docwiki.embarcadero.com/RADStudio/XE2/en/Creating_Your_First_FireMonkey_Application_for_Desktop_Platforms_%28C%2B%2B%29
The more terse and no picture procedure is here titled Steps in Creating Cross-Platform Applications:
http://docwiki.embarcadero.com/RADStudio/XE2/en/Steps_in_Creating_Cross-Platform_Applications
The Windows centric procedure and a small screen capture is here titled 64-bit Cross-Platform Application Development for Windows:
http://docwiki.embarcadero.com/RADStudio/XE3/en/64-bit_Cross-Platform_Application_Development_for_Windows
I have found on an Embarcadero forum post that an upgrade to the Update 1 XE3 release from the original XE3 release has a Target Platform selection issue. There can be an internal path setting or two that is incorrect, and possibly having to change an original XE3 project file (.cbproj) to enable Win64. Apparently the original release project file has this set to false.
XE5 (note version five as of December 2013) is supposed to have 64-bit Windows support for both console and forms applications (e.g. VCL, FireMonkey Desktop, FireMonkey Metropolis), OS X, iOS (Android coming sometime soon). For the complete list, review the C++Builder feature matrix pdf for all of the XE5 details:
http://www.embarcadero.com/products/cbuilder/cbuilder-feature-matrix.pdf
Since the XE3 Update 1 has been shown to resolve Target Platform selection issues, when compared to the original XE3, there should not be any weird behaviors. I have also come across an Embarcadero post that states from a TeamB member that for mobile applications, the Target Platform choices are filtered such that mixing a desktop platform project with a mobile one is not allowed. So, if one wanted to try creating a desktop application and then with a mouse click force it into an iPhone, some other development tool will have to be used. C++Builder and/or Delphi will not attempt to squeeze desktop components onto a mobile device. You have to start with a mobile application project. Here is the forum link:
https://forums.embarcadero.com/thread.jspa?threadID=96371
(End Edit)
If curious about my overall background, I have used C++Builder since version one, Visual Studio .NET (C# 1.0) and Visual Studio 2010 Ultimate. It seems like Visual Studio concentrates on C# more than any other language. There are eighteen C# projects and fifteen C++ projects when selecting File | New Project. To reach the Visual Studio C++ project area, make sure to reach it by opening the "Other Languages" sub-tree.
In recent Internet posts between Visual Studio latest and greatest and C++Builder latest and greatest, purchase prices vary in the thousands of dollars. Even if never ever having an installation to upgrade either tool, C++Builder remains a bargain compared to Visual Studio. Please conduct thorough research before spending your hard earned cash. Hopefully both tools have 30-day trial installations to compare side by side, as your mileage may vary.

Where is a good place for a code review?

A few colleagues and I created a simple packet capturing application based on libpcap, GTK+ and sqlite as a project for a Networks Engineering course at our university. While it (mostly) works, I am trying to improve my programming skills and would appreciate it if members of the community could look at what we've put together.
Is this a good place to ask for such a review? If not, what are good sites I can throw this question up on? The source code is hosted by Google Code (http://code.google.com/p/nbfm-sniffer) and an executable is available for download (Windows only, though it does compile on Linux and should compile on OS X Leopard as well provided one has gtk+ SDK installed).
Thanks, everyone!
-Carlos Nunez
UPDATE: Thanks for the great feedback, everyone. The code is completely open-source and modifiable (licensed under Apache License 2.0). I was hoping to get more holistic feedback, considering that my postings would still be very lengthy.
As sheepsimulator mentioned, GitHub is good. I would also recommend posting your project on SourceForge.net and/or FreshMeat.net. Both are active developer communities where people often peruse projects like yours. The best thing for your code would be if someone found it useful and decided to extend it. Then, you'd probably end up with plenty of bug fixes and constructive criticism.
You might get some mileage by posting the code out in the public space (through github or some other open-posting forum), putting a link here on SO, and seeing what happens.
You could also make it an open-source project, and see if people find it and use it.
Probably your best bet is to talk to your prof/classmates, find some professional programmers willing to devote their time, and have them review the code. Like American Idol-esque judging, but for your software...
As #Noah states, this is not the site for code review. You may present problems and what you did to overcome those problems, asking if a given solution would be the best.
I found a neat little website that might be what you are looking for: Cplusplus.com

Is there a C++ gdb GUI for Linux? [closed]

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.

Programs don't work on Vista and Server 2008

Many, if not all, of my old VC++ 6.0 MFC apps don't work in Vista and Server 2008. I had that migration was a problem, but now it's my problem :(
How do I go about making these things work? Is that possible? I've searched, but is there some repository of knowledge on this subject?
edit:
Compatibility mode seems to work.
There should be specific reasons why they don't work, and of course, what exactly does not work. Maybe you should break each issue into a separate question (maybe here at SO) and tell us exactly what kind of problems you have when you try to run them, and what is the code that makes those errors show up.
Without the details, it's too vague. There is no magic you can apply to make applications simply work just like that.
There's a document available here that explains how to develop UAC compliant applications.
Without recompiling, have you tried setting the compatibility mode on the program to Windows 98 or ME?