添加向量时出现分段错误。 (C++)
所以我有一个非常基本的类，它有一些方法和一些类变量。一切都工作得很好，直到我向头文件中的成员变量添加一个向量：
std::vector <std::string> vectorofstuff;
如果我所做的只是添加这一行，那么我的程序运行完美，但最后，在所有输出都在那里之后，我收到一条有关 seg 的消息过错。
我的第一个猜测是我需要在向量上调用析构函数，但这似乎不起作用。另外，我的理解是我不需要调用析构函数，除非我使用“新”一词。
有朝正确方向推动的吗？谢谢各位！
So I've got a pretty basic class that has a few methods and some class variables. Everythings working great up until I add a vector to the member variables in the header file:
std::vector <std::string> vectorofstuff;
If all I do is add this line then my program run perfectly but at the end, after all the output is there, I get a message about a seg fault.
My first guess is that I need to call the destructor on the vector, but that didn't seem to work. Plus my understanding is I don't need to call the destructor unless I use the word 'new'.
Any pushes in the right direction? Thanks bunches!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我猜想以下情况要么发生在您身上，要么是类似的涉及未实现的依赖项/标头的事情。不管怎样，我希望这个答案可能会出现在谷歌上，并帮助一些后来极度困惑的程序员弄清楚为什么他们突然观察到任意崩溃。
因此，根据经验，如果您编译新版本的
SomeObject.o但意外地拥有另一个目标文件#include旧版本的SomeObject.hpp，则可能会发生这种情况。这会导致损坏，这是由编译器引用过时的成员偏移量等引起的。有时，这主要有效，并且仅在破坏对象时才会产生段错误 - 无论是相关的还是看似遥远的对象 - 而其他时候，程序会立即或在某个地方出现段错误中间；我见过几种排列（遗憾的是！）。对于任何想知道为什么会发生这种情况的人来说，也许这只是我在编程时睡眠不足的反映，但我在 Git 子模块的上下文中遇到了这种模式，例如：
MyRepoGuiSubmoduleHelperSubmoduleGuiSubmodule如果 (A) 你在
GuiSubmodule中有一个新的提交，目前还没有被拉入HelperSubmodule的副本中，(B) 您的makefile编译MyRepo/uiSubmodule/SomeObject.o，以及 (C) 另一个翻译单元- 通过#include的危险在子模块或主存储库中 - 链接到具有不同类布局的旧版本SomeObject.hpp...正在享受一段有趣的时光，并且很多次追逐转移注意力，直到你最终意识到这个简单的错误。由于我从头开始拼凑了构建过程，因此我可能没有正确使用 Git/
make- 或者不够严格（忘记推/拉所有子模块）。大概是后者吧！至少现在我看到的奇怪错误少了:)I guess the following either happened to you, or it was something similar involving unrealised dependencies/headers. Either way, I hope this answer might show up on Google and help some later, extremely confused programmer figure out why they're suddenly observing arbitrary crashes.
So, from experience, this can happen if you compile a new version of
SomeObject.obut accidentally have another object file#includean old version ofSomeObject.hpp. This leads to corruption, which'll be caused by the compiler referring to outdated member offsets, etc. Sometimes this mostly works and only produces segfaults when destructing objects - either related or seemingly distant ones - and other times the program segfaults right away or somewhere in-between; I've seen several permutations (regrettably!).For anyone wondering why this can happen, maybe this is just a reflection of how little sleep I get while programming, but I've encountered this pattern in the context of Git submodules, e.g.:
MyRepoGuiSubmoduleHelperSubmoduleGuiSubmoduleIf (A) you have a new commit in
GuiSubmodule, which has not yet been pulled intoHelperSubmodule's copy, (B) yourmakefilecompilesMyRepo/uiSubmodule/SomeObject.o, and (C) another translation unit - either in a submodule or in the main repo via the perils of#include- links against an older version ofSomeObject.hppthat has a different class layout... You're in for a fun time, and a lot of chasing red herrings until you finally realise the simple mistake.Since I had cobbled together my build process from scratch, I might've just not been using Git/
makeproperly - or strictly enough (forgetting to push/pull all submodules). Probably the latter! I see fewer odd bugs nowadays at least :)您可能正在破坏类中某处
vectorofstuff成员的内存。当类析构函数被调用时，向量的析构函数也会被调用，它会尝试指向和/或删除无效内存。You are probably corrupting the memory of the
vectorofstuffmember somewhere within your class. When the class destructor is called the destructor of the vector is called as well, which would try to point and/or delete to invalid memory.我正在胡闹，为了确定起见，我决定对所有内容进行 rm 并重新编译。你猜怎么着？这解决了它。我不知道为什么，在 makefile 中我无论如何都会这样做，但无论如何，我很高兴我可以继续前进并继续工作。非常感谢您的所有帮助！
I was fooling around with it and decided to, just to be sure, do an rm on everything and recompile. And guess what? That fixed it. I have no idea why, in the makefile I do this anyway, but whatever, I'm just glad I can move on and continue working on it. Thanks so much for all the help!