C++动态数组智能指针管理方法

最推荐使用 std::unique_ptr<T[]> 管理动态数组，因其能自动调用 delete[] 避免内存泄漏；若需共享所有权，可用带自定义删除器的 std::shared_ptr；但多数情况下应优先选用 std::vector，因其兼具自动管理、丰富接口与优良性能。

在C++中，管理动态数组与智能指针结合使用，最直接且推荐的方式是利用 std::unique_ptr<T[]>。它专为动态数组设计，能确保在对象生命周期结束时自动调用正确的 delete[] 操作，从而避免内存泄漏。如果确实需要共享所有权，std::shared_ptr 也能做到，但它需要一个自定义的删除器来正确处理数组释放。不过，话说回来，在大多数现代C++场景里，std::vector 往往是更安全、更方便且性能同样出色的默认选择。

解决方案

当我们需要在堆上分配一个动态数组时，传统的做法是使用 new T[size]，然后手动 delete[]。这极易出错，稍不留神就会忘记释放内存，或者更糟的是，用 delete 而非 delete[] 释放数组，导致未定义行为。智能指针的出现就是为了解决这类问题。

1. std::unique_ptr<T[]>：独占所有权的最佳选择

这是管理动态数组最直接、最安全的方法，尤其当你确定数组的生命周期与智能指针的生命周期完全绑定，且没有其他地方需要共享该数组时。std::unique_ptr 有一个特化版本 std::unique_ptr<T[]>，它明确知道自己管理的是一个数组，因此在析构时会自动调用 delete[]。

#include <memory>
#include <iostream>

void process_data(int* arr, size_t size) {
    for (size_t i = 0; i < size; ++i) {
        arr[i] *= 2;
    }
}

int main() {
    // 创建一个包含10个int的动态数组
    std::unique_ptr<int[]> arr_ptr = std::make_unique<int[]>(10); // C++14及更高版本推荐
    // 或者 C++11 风格：
    // std::unique_ptr<int[]> arr_ptr(new int[10]); 

    for (int i = 0; i < 10; ++i) {
        arr_ptr[i] = i + 1; // 像普通数组一样访问元素
    }

    std::cout << "Original array elements: ";
    for (int i = 0; i < 10; ++i) {
        std::cout << arr_ptr[i] << " ";
    }
    std::cout << std::endl;

    // 可以获取原始指针传递给C风格API
    process_data(arr_ptr.get(), 10);

    std::cout << "Processed array elements: ";
    for (int i = 0; i < 10; ++i) {
        std::cout << arr_ptr[i] << " ";
    }
    std::cout << std::endl;

    // arr_ptr超出作用域时，会自动调用 delete[] arr_ptr.get()
    return 0;
}

std::make_unique<int[]>(10) 是C++14引入的，它避免了显式 new，并提供了异常安全保证，我个人觉得，这是更现代、更安全的写法。

2. std::shared_ptr 与自定义删除器：共享所有权

如果你的动态数组需要被多个 std::shared_ptr 实例共享，那么情况就稍微复杂一点。std::shared_ptr 的默认删除器只会调用 delete，而不是 delete[]。这意味着，如果你直接这样用：std::shared_ptr<int> shared_arr(new int[10]);，那么在 shared_arr 析构时，会调用 delete 而不是 delete[]，这会导致未定义行为。

正确的做法是提供一个自定义的删除器（通常是一个lambda表达式），明确告诉 std::shared_ptr 如何释放数组内存：

#include <memory>
#include <iostream>
#include <vector> // 后面会提到

int main() {
    // 使用自定义删除器管理动态数组
    std::shared_ptr<int> shared_arr(new int[10], [](int* p) {
        std::cout << "Custom deleter called for shared_arr, deleting array." << std::endl;
        delete[] p;
    });

    for (int i = 0; i < 10; ++i) {
        shared_arr.get()[i] = (i + 1) * 10; // 通过get()获取原始指针访问
    }

    // 可以创建其他shared_ptr实例共享所有权
    std::shared_ptr<int> another_shared_arr = shared_arr;

    std::cout << "Shared array elements: ";
    for (int i = 0; i < 10; ++i) {
        std::cout << shared_arr.get()[i] << " ";
    }
    std::cout << std::endl;

    // 当所有shared_ptr实例都超出作用域时，自定义删除器会被调用一次
    return 0;
}

这里有个细节，std::shared_ptr<int> 而不是 std::shared_ptr<int[]>。这是因为 std::shared_ptr 没有像 std::unique_ptr 那样为数组提供特化版本。因此，当你使用 std::shared_ptr 管理数组时，你实际上是管理一个指向数组第一个元素的指针，并依赖自定义删除器来正确地释放整个数组。访问元素时，你需要通过 get() 方法获取原始指针，然后进行指针算术或使用下标操作符。

3. std::vector：大多数情况下的首选

我个人认为，除非有非常特殊的原因，比如需要与C风格API高度兼容，或者对内存布局有极致的控制需求，否则 std::vector 几乎总是管理动态数组的最佳选择。它提供了RAII（资源获取即初始化），自动内存管理，以及丰富的API（如迭代器、容量管理、元素访问方法等），并且通常在性能上与原始数组不相上下。

#include <vector>
#include <iostream>

int main() {
    std::vector<int> vec(10); // 创建一个包含10个int的动态数组

    for (int i = 0; i < 10; ++i) {
        vec[i] = i * 100; // 像普通数组一样访问元素
    }

    std::cout << "Vector elements: ";
    for (int i = 0; i < vec.size(); ++i) {
        std::cout << vec[i] << " ";
    }
    std::cout << std::endl;

    // vec超出作用域时，会自动释放内存
    return 0;
}

std::vector 内部已经处理了内存的分配和释放，并且提供了类型安全和边界检查（在调试模式下）。它的接口设计也更加现代化和易用。

为什么不能直接用 std::unique_ptr<T> 管理数组？

这是一个非常常见的误区，我见过不少新手会犯这样的错误。核心问题在于 std::unique_ptr<T> 和 std::unique_ptr<T[]> 在析构时调用的内存释放函数不同。

当你声明 std::unique_ptr<T> ptr(new T[size]); 时，你创建了一个 unique_ptr，它被设计来管理单个对象 T。因此，当 ptr 超出作用域时，它的析构函数会调用 delete ptr.get();。

然而，如果你用 new T[size] 分配了一个数组，正确的释放方式是 delete[] ptr.get();。

所以，当 delete 被用于释放通过 new[] 分配的内存时，就会导致未定义行为（Undefined Behavior, UB）。这意味着程序可能会崩溃，可能会泄漏内存，也可能表面上看起来正常运行，但在未来的某个时刻，在某个不相关的代码路径中，问题会突然暴露出来，这种错误调试起来非常痛苦。

简单来说，delete 和 delete[] 不是可以互换的。delete 针对单个对象，delete[] 针对数组。它们在底层可能执行完全不同的操作，例如 new[] 可能会在实际数据之前存储数组的大小信息，而 delete[] 会利用这些信息。如果只调用 delete，这些信息可能不会被正确处理，导致内存损坏。

// 错误的示例，会导致未定义行为！
std::unique_ptr<int> bad_array_ptr(new int[10]); 
// 当 bad_array_ptr 析构时，会调用 delete (int*) 而不是 delete[] (int*)
// 这就是问题所在。

所以，请务必记住：管理动态数组，要用 std::unique_ptr<T[]>，而不是 std::unique_ptr<T>。这是C++类型系统和内存管理规则的一个重要细节。

在 std::shared_ptr 中管理动态数组需要注意什么？

正如前面提到的，std::shared_ptr 在设计上没有为数组提供像 std::unique_ptr 那样的特化版本。这意味着，如果你想用 std::shared_ptr 来管理 new T[size] 分配的动态数组，你必须提供一个自定义的删除器。

最关键的注意事项就是：不要忘记自定义删除器，并且确保删除器调用的是 delete[]。

// 错误示范：没有自定义删除器
// std::shared_ptr<int> my_shared_array(new int[5]); // 同样是未定义行为！

// 正确示范：使用lambda表达式作为自定义删除器
std::shared_ptr<int> my_shared_array_correct(new int[5], [](int* p) {
    std::cout << "Custom deleter for shared_ptr array called." << std::endl;
    delete[] p; // 确保是 delete[]
});

自定义删除器是一个可调用对象（函数指针、函数对象或lambda），它接受一个原始指针作为参数，并负责释放该指针指向的资源。std::shared_ptr 会在最后一个引用计数归零时调用这个删除器。

如果你忘记提供自定义删除器，std::shared_ptr 会使用其默认的删除器，它会调用 delete。这和 std::unique_ptr<T> 犯的错误一样，导致未定义行为。

此外，需要注意的是，当使用 std::shared_ptr 管理数组时，你通常需要通过 get() 方法获取原始指针来访问数组元素，例如 my_shared_array_correct.get()[i]。这是因为 std::shared_ptr<T> 的 operator[] 没有为数组语义重载，它只是一个指向单个 T 的智能指针。

虽然 std::shared_ptr 提供了这种灵活性，但它也带来了一定的开销。std::shared_ptr 需要维护一个控制块来存储引用计数和删除器等信息，这会占用额外的内存。而且，引用计数的增减通常涉及到原子操作，这在多线程环境下会引入同步开销。因此，除非你确实需要共享动态数组的所有权，否则 std::unique_ptr<T[]> 或 std::vector 往往是更轻量级的选择。

什么时候应该优先考虑 std::vector 而不是智能指针管理动态数组？

在我看来，这是一个非常实际的问题，也是现代C++编程中一个重要的设计决策。我几乎可以说，在绝大多数情况下，std::vector 都应该成为你管理动态数组的首选，而不是直接使用智能指针来包装 new T[]。

以下是我个人总结的一些理由，说明为什么 std::vector 常常是更好的选择：

1. RAII 的完整实现与自动内存管理： std::vector 内部已经完美地实现了RAII。你不需要担心 new 和 delete[] 的配对，它会自动处理内存的分配和释放。这大大减少了内存泄漏和悬空指针的风险。
2. 丰富的API和功能： std::vector 不仅仅是一个内存容器，它是一个功能完备的序列容器。它提供了：
   • 动态大小调整： 你可以方便地添加或删除元素，std::vector 会自动处理内存的重新分配。这是 new T[] 无法直接提供的。
   • 迭代器支持： 可以轻松地与STL算法（如 std::sort, std::for_each 等）配合使用。
   • 边界检查： at() 方法提供运行时边界检查（尽管 operator[] 不提供，但调试时可以帮助发现问题）。
   • 容量管理： capacity(), reserve(), shrink_to_fit() 等方法可以让你更好地控制内存使用。
   • 构造函数和赋值操作： 提供了方便的复制、移动语义。
3. 类型安全： std::vector<T> 明确表示它包含 T 类型的元素，并提供类型安全的访问。
4. 性能通常足够好： 很多人可能误以为 std::vector 会有很大的性能开销。但实际上，现代C++编译器对 std::vector 的优化非常到位。它的元素是连续存储的，这与原始数组一样，因此缓存局部性很好。对于绝大多数应用来说，std::vector 的性能表现与原始数组几乎没有区别，甚至在某些情况下可能因为更好的内存管理策略而表现更优。
5. 与现代C++生态系统的无缝集成： std::vector 是STL的核心组件，与C++标准库中的其他部分（如算法、迭代器）配合得天衣无缝。

那么，什么时候会考虑智能指针管理 new T[] 呢？

1. C风格API的互操作性： 当你需要将一个动态数组的原始指针传递给一个只接受 T* 或 void* 的C风格函数或库时，std::unique_ptr<T[]>::get() 或 std::shared_ptr<T>::get() 就可以派上用场。虽然 std::vector<T>::data() 也能提供这个功能，但在某些特定场景下，智能指针可能更直接。
2. 极度内存敏感或特殊分配需求： 某些非常底层或嵌入式系统编程中，你可能需要使用自定义的内存分配器（例如，从预分配的内存池中分配），而这些分配器可能不兼容 std::vector 的默认行为。在这种情况下，手动 new T[size] 并用智能指针管理可能是一种选择。但这非常罕见，且需要深入理解内存管理。
3. 遗留代码的现代化： 如果你正在处理大量使用 new T[] 的遗留C++代码，并且希望逐步引入RAII，那么将这些裸指针包装到 std::unique_ptr<T[]> 或 std::shared_ptr<T>（带自定义删除器）中，是一个相对低风险的重构策略。

总而言之，我的建议是：总是从 std::vector 开始考虑。只有当 std::vector 明确无法满足你的特定需求（通常是与C接口的深度集成或极端的自定义内存管理）时，才转向 std::unique_ptr<T[]>。而 std::shared_ptr 管理动态数组，则是在需要共享所有权且必须使用 new T[] 时的最后手段。 这样做能让你的代码更健壮、更易读、更易维护。