21–30 of 42 posts
Earlier quoted context omitted.
> VS has the best debugger Not to nitpick or disregard the rest of your comment (VS has a really good debugger), but "best" always required qualifying. Best in what cases? Best in what way? There are times when the "best" debugger available without a doubt is WinDbg, with it being archaic, oldfashioned, command-line based, completely un-automated and all that fully accounted for. Why? Because I can copy the 500KB exe…
VS can debug processes on remote machines with only a small helper process running on that machine, and while you shouldn't deploy PDBs onto your production servers, there's no reason not to generate them for your release builds.
Visual Studio misses features like Python scripting, which for instance in gdb allows you to define pretty printers for your objects, which is immensely useful for complex data structures. The VS debugger also does not have a proper MI, at least I never heard of one. The only thing I miss from gdb is "edit and continue", which I admit is pretty cool.
Earlier quoted context omitted.
You can. I just drag the arrow that appears on broken execution "upwards" to a previous line of code. There might be another way to do it.
Does this undo previous commands or does it just rerun code?
I personally don't use debugger that much but whenever I have used it, I have always been amazed at VS's debugger capability. I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms. I think this is a GREAT news for all the developers.
Are there any features in VS debugger that are better or non-existent in Java IDEs?
Earlier quoted context omitted.
VS can debug processes on remote machines with only a small helper process running on that machine, and while you shouldn't deploy PDBs onto your production servers, there's no reason not to generate them for your release builds.
http://en.wikipedia.org/wiki/Gdbserver Visual Studio misses features like Python scripting, which for instance in gdb allows you to define pretty printers for your objects, which is immensely useful for complex data structures. The VS debugger also does not have a proper MI, at least I never heard of one. The only thing I miss from gdb is "edit and continue", which I admit is pretty cool.
I personally don't use debugger that much but whenever I have used it, I have always been amazed at VS's debugger capability. I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms. I think this is a GREAT news for all the developers.
I've seen this best debugger thing come up a few times before. I'm currently working with windows on a project right now and I'm finding the VS debugger more limited than GDB. With GDB I can create scripts which analyse and print complex memory layouts very quickly and efficiently. With valgrind, I can find memory leaks and other unwanted behaviors. With gcc's dump-tree family of options, I can see how my code is tur…
Things I quite like about it:
- no grammar to the command set, just keypresses, and no need to press Return. gdb drives me nuts with its command line... feels like trying to count while somebody shouts random numbers in my ear. I'd probably get on better with a command-line driven version of Photoshop than I do with command-line controlled debuggers
- passable support for mixed assembly language/source code debugging (same step commands in all cases)
- dockable UI that's satisfactorily configurable and updates as you work, so you can see a lot of stuff at once. I find the gdb text-based UI like trying to look through a telescope the wrong way, and it's even worse if you go for the line-by-line TTY mode
- it displays code using the normal VS editor, so you can use the code browsing functionality to look around the code as you work
There's plenty of scope for improvement, so while it does a reasonable job, I'm maybe not sure about "best". But... I don't appear to be unique in preferring it to gdb. So if we're going for some kind of democratic vote, then maybe an argument could be made ;)
But overall, the main thing I like about the VS debugger is that it's integrated quite well into the VS workflow. When you run your project in VS, you run it under the debugger. You have other options, it's true - but running under the debugger is the most obvious one, so that's what you do. There are times where you need rather complicated stuff doing, and VS is sadly lacking in that regard. But most of the time, when your code fucks up, the VS debugger provides enough to let you figure the problem out, and your code is already running under it, so there you go.
(I never found a way to get gdb working quite so well - it starts out with your process stopped, for example, so you have to type "run" to get it going. And I never figured out any way to stop your process without being dumped back to the gdb prompt, like Shift+F5 in Visual Studio. If I actually liked working in gdb, I'd probably just get over this, and/or put the time in to figure out how to fix it. But... I don't.)
I personally don't use debugger that much but whenever I have used it, I have always been amazed at VS's debugger capability. I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms. I think this is a GREAT news for all the developers.
I've seen this best debugger thing come up a few times before. I'm currently working with windows on a project right now and I'm finding the VS debugger more limited than GDB. With GDB I can create scripts which analyse and print complex memory layouts very quickly and efficiently. With valgrind, I can find memory leaks and other unwanted behaviors. With gcc's dump-tree family of options, I can see how my code is tur…
I personally don't use debugger that much but whenever I have used it, I have always been amazed at VS's debugger capability. I don't think I am exaggerating when I say that VS has the best debugger across all languages/platforms. I think this is a GREAT news for all the developers.
Have you used any of the debuggers one finds in Smalltalk environments, out of interest?
EDIT: typo
I've been using VisualGDB at work to do embeeded programming on a Cortex M4. Hopefully these guys can benefit from this new Microsoft code, as some things like expression eval don't work in VisualGDB.