簡體   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