11–20 of 42 posts
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 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.
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-file into a production environment, run it there and debug issues found nowhere else.
And obviously you're not going to install VS on your production-server, and if you did, those builds are release-builds anyway, without debug-assistance or PDBs, so the VS-debugger would be handicapped anyway.
So yeah. Just a slight nit-pick that "best" always has to be qualified.
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.
> 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…
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.
You cannot step back with VS's debugger, can you?
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.
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.
You first please :)
I've tried doing that several times and always ended up giving up. If it's not firewalling, its UAC or cross domain trust issues, or DCOM configuration, or process permissions and probably 200 other things which has failed on me in the past.
It only works in the most trivial of configurations. Back in the real world I've only been able to use it once or twice, non-repeatably.
Not to be confused with the RC that got released today, which isn't actually a Release Candidate.
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.
> VS can debug processes on remote machines with only a small helper process running on that machine You first please :) I've tried doing that several times and always ended up giving up. If it's not firewalling, its UAC or cross domain trust issues, or DCOM configuration, or process permissions and probably 200 other things which has failed on me in the past. It only works in the most trivial of configurations. Back…
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…
For people accustomed to IDEs, the fact that they don't have to remember "n" means "next," "s" means "step into," "info breakpoints" will say which breakpoints you've set, etc. is a big deal. Yes, you can use DDD for that, but frankly, it doesn't look as nice.
Additionally, if you want to see what value a variable has, simply hover over it with the mouse pointer. This works for ints, but it also works for std::vector >. You can get the same functionality in GDB, but it takes a little work to set it up.
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…
It's not (just) features, it's the interface to those features. The possibility cap may be lower for you, but that doesn't matter to people who just want an approachable interface to step through their code.
This is the part where I'm an elitist asshole: There are developers that program by spending all day, every day in the debugger. They're almost never going to do anything fancy, they just want an easy way to fix their code. Command line gdb is too much effort to learn, and of the IDEs that hook into debuggers, VS does it the best.