繁体   English   中英

istream_iterator泄漏内存

[英]istream_iterator leaking memory

好的,你们对我的最后一个问题非常有帮助,因此我将尝试另一个问题。 这也是家庭作业,虽然最后一个很旧,但已提交,正在等待标记。 因此,如果有什么东西会咬我,可能就是这个问题。 我已经混淆了班级名称,因为这样仍然可以提交作业(对于其他学生)。

我有一个类,其唯一成员是指向对象的指针。 构造该类是为了从其当前持有的指针中公开某些操作Object *o_Object{1, 2, 3, ...}的基类。 现在,我可以执行以下操作,而不会发生任何内存泄漏或崩溃。

std::vector<ObjectPtr> v;
v.push_back(ObjectPtr(new Object1(..., ..., ...)));
v.push_back(ObjectPtr(new Object2(..., ...)));
v.push_back(ObjectPtr(new Object1(.., .., ..)));

// Copy Constructor Ptr
std::vector<ObjectPtr> v2(v);
// Assignment Operator Ptr
std::vector<ObjectPtr> v3;
v3 = v2;

所有这些都有效,并且没有内存泄漏。 但是,如果我尝试使用istream_iterator<ObjectPtr>从文件中读取内容,它将开始泄漏。 ObjectPtr是唯一处理动态内存的类,并且Object *o_设置为NULL或由Object{1, 2, 3, ...}分配。

要读取的文件如下所示

Object1
...
...
Object2
...
...
Object1
..
std::ifstream is("file.txt");
std::istream_iterator<ObjectPtr> in(is), end;
for (; in != end; ++in)
    cout << *in << "\n";

用于读取这些值的ObjectPtr中的ObjectPtr函数看起来像

friend istream &operator>>(istream &is, ObjectPtr &op) {
    std::string tmp;
    while (std::getline(is, tmp)) {
        if (tmp == "Object1") {
            op.o_ = new Object1;
            return is >> (Object1 &)*(op.o_); // Send it to operator>> for Object1
        }
        if (tmp == "Object2") {
            op.o_ = new Object2;
            return is >> (Object2 &)*(op.o_);
        }
        ...
    }
    return is;
}

在这里的某个地方,它开始对我独角兽,我真的很想知道为什么。

简而言之-istream_iterator会在分配和复制构造函数正常工作时泄漏内存,这使我相信Object{1, 2, 3, 4, ..}类的构造正确,而问题将在operator>>发现。 operator>>

这是我发生的第一件事。 我不知道这是否是您要寻找的问题:

friend istream &operator>>(istream &is, ObjectPtr &op) {
    std::string tmp;
    while (std::getline(is, tmp)) {
        if (tmp == "Object1") {
            op.o_ = new Object1;

在最后一行中, op.o的旧值会op.o
请记住,流式传输到对象意味着要流式传输到完全构造的对象,而您必须注意该对象的旧数据。 (这就是为什么通常偏爱使用std::istream 构造函数的原因。对于复杂的对象,该对象可以安全地保护将在下一刻更改的对象的初始化。)

ObjectPtr是否具有赋值运算符或swap()成员函数? 如果是这样,通过构造一个新对象并使用op将其分配给/交换它可能更容易实现输入运算符。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM