C でオブジェクト ポインターのベクトルを使用するときにメモリ リークを防ぐにはどうすればよいですか?

オブジェクト ポインターのベクトルを使用する場合のメモリ リークの回避

C で動的に割り当てられたオブジェクトへのポインターのベクトルを使用する場合、潜在的なメモリ リークを理解し、適切なメモリ管理手法を採用することが重要です。

ベクターは、メモリ割り当てを自動的に管理します。ただし、ポインターのベクトルの場合、割り当てられたメモリはポインターに属し、ポインターが表すオブジェクトには属しません。これは、ベクトルがスコープ外になると、その内容 (ポインター) が解放され、割り当てられたオブジェクト メモリがぶら下がったままになり、メモリ リークが発生する可能性があることを意味します。

この問題を防ぐには、ベクトルがスコープ外になる前に、割り当てられたすべてのオブジェクトを削除します。 1 つのアプローチは、ベクトルを手動で繰り返し、各ポインターで delete を呼び出すことですが、これはエラーが発生しやすく不便です。

より良い解決策は、自動メモリ管理を提供するスマート ポインターを利用することです。スマート ポインターには、unique_ptr とshared_ptr の 2 つの主なタイプがあります。

std::unique_ptr

std::unique_ptr は、リソースの単一の所有権を表します。 unique_ptr がスコープ外になると、所有されているメモリが自動的に解放されます。これにより、メモリ リークのリスクが排除され、対応するオブジェクトが不要になったときに確実に割り当て解除されます。

例:

#include <memory>
#include <vector>

struct base
{
    virtual ~base() {}
};

struct derived : base {};

typedef std::vector<std::unique_ptr<base>> container;

void foo()
{
    container c;

    for (int i = 0; i < 100; ++i)
        c.push_back(std::make_unique<derived>());

} // all automatically freed here

int main()
{
    foo();
}

std::shared_ptr

std::shared_ptr は共有所有権向けに設計されています。参照カウントを使用して、オブジェクトを指す共有ポインターの数を追跡します。最後のshared_ptrがスコープ外になると、未処理のコピーまたは参照の数に関係なく、所有メモリの割り当てが解除されます。

例:

#include <memory>
#include <vector>

struct base
{
    virtual ~base() {}
};

struct derived : base {};

typedef std::vector<std::shared_ptr<base>> container;

void foo()
{
    container c;

    for (int i = 0; i < 100; ++i)
        c.push_back(std::make_shared<derived>());

} // all automatically freed here

int main()
{
    foo();
}

通常、より軽量なメモリ管理を提供するため、 std::unique_ptr を使用することをお勧めします。ただし、std::shared_ptr は、所有権の共有が必要な場合や、既存の生のポインタをスマート ポインタに変換する必要がある場合に役立ちます。

代わりに、boost::ptr_container はコンテナ クラスを提供するライブラリです。ポインタを格納するために特別に設計されています。前述のスマート ポインターと同様に、メモリ管理を自動化します。

使用するアプローチに関係なく、適切なメモリ管理方法を採用し、手動による明示的なリソースの割り当て解除を回避することが最も重要です。これはメモリ リークや予測不可能な動作につながる可能性があるためです。アプリケーション内で。

以上がC でオブジェクト ポインターのベクトルを使用するときにメモリ リークを防ぐにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。