Visual Studio Users and Eclipse
I’m working on a presentation for this year’s EclipseCon titled “Visual Studio Users and Eclipse” A lot of people using Carbide have also used Visual Studio and have given us lots of feedback about their experiences trying out a new C/C++ environment. While the C/C++ people are very active in the Eclipse community the crowd at EclipseCon has more of an enterprise/java/open source background. So I hope to use the presentation to build awareness around some of the issues people have when they come to Eclipse from Visual Studio. Some of these are unique to Carbide, some are things we can contribute to the Eclipse community, and some are things we need to convince other contributers to pay attention to.
In Carbide 1.3 we added a set of Visual Studio key bindings, a couple new editor commands, better contextual launching for the debugger, and other usability improvements in response to your feedback. If you can suggest other things we can do to Carbide to make it more accessible to VS users please leave a comment or file a bug and I’ll try to work them into my presentation.
And if you find yourself at EclipseCon be sure to come by and say hello.
I am not sure if this is already on your list, but one of the few things I find myself going back to VS6 for is thread display in the emulator (yes, I know that I seem to be one of the few who don’t care much for ODD ;-)):
Carbide will only show you the Windows thread ID for each running thread, but there is no indication as to which threads belong to which process (neither is there in VS), and more importantly, I can’t seem to get a quick overview of what each thread is doing at the moment.
I would like to get a summary of the first position in the call stack for which there is symbolic debugging information - this is exactly what the thread display of VS gives me, so if my application hangs, I can simply pause the emulator (all threads) and then see in a single view what each thread is doing.
The equivalent possibility of breaking all threads in Carbide is so slow in populating all the levels of the tree that I find it virtually unusable for the hundreds of threads in a typical Symbian emulator session.
Another area that I still use VS6 for is raw memory views - if I have to inspect, say, a region of the heap around a corrupted cell, I find the Carbide memory view much more limiting in how it lets me move around, especially to areas before the location I have specified.
For Symbian specifically (though not Eclipse in general) one possibility to improve these two areas might be integrating Symbian’s HookLogger and AnalyzeHeap tools.