调试 C++与调试 C 相比
嗨，
我通常是一名 C 程序员。 我经常使用 gdb、dbx 等工具在 UNIX 环境下调试 C 程序。 我从来没有调试过 C++ 的大型应用程序。 这与我们在 C 中调试的方式有很大不同吗？ 理论上我在 C++ 方面相当不错，但从未有机会调试 C++ 程序。 我也不确定我们在 C++ 中面临什么样的技术问题，这会导致开发人员打开调试器来找出问题。 我们在 C++ 中遇到哪些常见问题会导致调试器启动？
ac 程序员在调试 C++ 程序时可能面临哪些挑战？ 与C相比，它是困难和复杂的吗？
HI,
I am normally a C programmer.
I do regularly debug C programs on unix environment using tools like gdb,dbx.
i have never done debugging of big applications of C++.
Is that much different from how we debug in C.
theoretically i am quite good in C++ but have never got a chance to debug C++ programs.
I am also not sure about what kind of technical problems we face in c++ which will lead a developer to switch on the debugger for finding out the problem.
what are the common issues we face in C++ which will make debugger to be started
what are the challenges that a c programmer might face while debugging a C++ program?
Is it difficult and complex when compared to C?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
基本上是一样的。
请记住，手动设置断点时，您需要使用命名空间和类来完全限定方法名称（因此，有时我发现使用行号来定义断点更容易）
不要忘记调用析构函数在源代码中是不可见的，但您仍然可以在块的末尾单步执行它们。
It is basically the same.
Just remember when setting break points manually you need to fully qualify the method name with both the namespace(s) and class (As a resul i someti es find it easier to use line numbers to define break points)
Don't forget that calls to destructors are invisible in the source, but you can still step into them at the end of a block.
一些细微的差别：
在 gdb shell 中输入诸如 foo::bar::fum(args) 之类的完全限定符号时，必须以单引号开头，以便 gdb 识别并计算完成情况。
正如其他人所说，库模板在调试器中公开其内部结构。您可以很容易地浏览
std::vector，但浏览std::map可能不是一个明智的消磨时间的方式。C++ 程序中常见的激进且丰富的内联可以使一行代码看似无穷无尽的步骤。像shared_ptr这样的事情可能特别烦人，因为对指针的每次访问都会内联扩展到模板内部。你永远不会真正使用它。
如果您有大量重载的符号名称，那么从 readline 补全中选择您想要的符号名称可能会很不愉快。 （你想要哪个“foo”？全部？就这两个？）
A few minor differences:
When typing a full-qualified symbol such as
foo::bar::fum(args)in the gdb shell you have to start with a single quote for gdb to recognize it and calculate completions.As others have said, library templates expose their internals in the debugger. You can poke around in
std::vectorpretty easily, but poking throughstd::mapmay not be a wise way to spend your time.The aggressive and abundant inlining common in C++ programs can make a single line of code have seemingly endless steps. Things like shared_ptr can be particularly annoying because every access to the pointer expands inline to the template internals. You never really get to used it.
If you've got a ton of overloaded symbol names, selecting which one you want from the readline completion can be unpleasant. (Which "foo" did you want? All of them? Just these two?)
GDB 也可以用来调试 C++，所以如果您了解 C++ 的工作原理（并且了解可能源于面向对象方面的问题），那么您就不应该遇到那么多麻烦（至少，与调试 C 程序没什么区别）。我认为...
GDB can be used to debug C++ as well, so if you have an understanding of how C++ works (and understand problems that can stem from the object-oriented side of things), then you shouldn't have all that much trouble (at least, not much more than you would debugging a C program). I think...
确实有很多问题，但它也取决于您使用的调试器、其版本控制等：
我喜欢调试器的好处是，要访问私有/受保护的类成员，我不必调用 get 例程；只需 [obj-name].[var-name] 就足够了。
阿尔潘
Quite a few issues really, but it also depends on the debugger you are using, its versioning etc:
The good thing that I like about debuggers is that to access private/protected class members I don't have to call get routines; just [obj-name].[var-name] is good enough.
Arpan
GDB 在调试 C++ 方面有着一段坎坷的过去。有一段时间它无法有效地破坏构造函数/析构函数内部。
此外，stl 容器在 gdb 中检查起来也非常困难。
std::string很痛苦，但通常是可行的。std::map太困难了，除非没有其他办法，否则我通常会添加 print 语句。构造函数/析构函数问题已经解决了几年。
gdb 7.0 中修复了 stl 支持。
您可能仍然对 boost 的库有问题。我有时很难让 gdb 为我提供
shared_ptr的内容。所以我想调试你自己的 C++ 并不是真的那么困难，调试第 3 方类和模板代码可能会出现问题。
GDB has had a rocky past with regard to debugging c++. For a while it couldn't efficiently break inside constructors/destructors.
Also stl container were netoriously difficult to inspect in gdb.
std::stringwas painful but generally workable.std::mapwas so difficult, that I generally added print statements unless there was no other way.The constructor/destructor problem has been fixed for a few years.
The stl support got fixed in gdb 7.0.
You might still have issues with boost's libraries. I at time had difficulty getting gdb to give me asses to the contents of a
shared_ptr.So I guess debugging your own C++ isn't really that difficult, it's debugging 3rd party classes and template code that could be a problem.
C++ 对象有时可能更难分析。此外，由于数据有时嵌套在多个类中（跨多个层），因此可能需要一些时间来“展开”它（正如本线程中的其他人已经说过的）。很难笼统地这么说，因为它很大程度上取决于所使用的 C++ 功能、编程风格以及要分析的问题的复杂性（实际上这是与语言无关的）。
IMO：如果有人发现自己需要经常调试，他应该重新考虑他的编程风格。
通常对我来说，这都是关于最后的错误处理。如果程序出现意外行为，您的错误日志应指示足够的信息来重建任何阶段发生的情况。
这还给您带来了一个好处，即一旦您的程序交付给最终用户，您就可以离线“调试”问题。
C++ objects might be sometimes harder to analyze. Also as data is sometimes nested in several classes (across several layers) it might take some time to "unfold" it (as already said by others in this thread). Its hard to generally say so, as it depends very much on C++ features used and programming style and complexity of the problem to analyze (actually that is language independent).
IMO: if someone finds himselfself in the need to debug very often he should reconsider his programming style.
Usually for me it is all about error handling at the end. If a program behaves unexpected your error logs should indicate enough information to reconstruct what happened at any stage.
This also gives you the benefit that you can "debug" problems offline later once your program gets shipped to end users.