get_temporary_buffer：被遗忘的C++临时内存“应急包”

你有没有写过这样的代码：需要临时存几十万个整数做中间计算，但又不想动用new——怕异常、怕泄漏、怕生命周期难管；用std::vector？又嫌它默认构造所有元素太重；手写malloc？那更得自己记着free，还绕不开对齐和类型安全……
这时候，std::get_temporary_buffer就像抽屉里那包没拆封的速溶咖啡——不常想起，但真到编译器报错、调试器卡住、性能 profiler 突然亮红灯时，翻出来冲一杯，还挺提神。

它不是标准容器，也不是智能指针，而是一个轻量级、无构造/析构语义、按需分配的原始内存借调接口。C++98 就有了，C++17 标记为 deprecated，C++20 正式移除——但它没消失，只是换了个更安静的方式活着：理解它，反而能帮你读懂 STL 底层逻辑，甚至在嵌入式或高性能场景里，悄悄绕过某些 allocator 的开销。

get_temporary_buffer 的核心契约很简单：
给你一块未初始化的、对齐的、类型安全的原始内存，不调用构造函数，也不承诺零初始化；你用完必须手动调用 return_temporary_buffer 归还——它不自动管理，只负责“暂借”。

比如你想快速排序一万个 double，但当前栈不够大，又不想触发 vector 的多次扩容：

std::pair<double*, std::ptrdiff_t> buf = 
    std::get_temporary_buffer<double>(10000);
if (buf.first == nullptr) {
    // 借失败了，降级处理（比如改用 vector 或抛异常）
    throw std::bad_alloc{};
}
// 注意：buf.first 指向的是 raw memory，不是已构造对象
// 不能直接写 buf.first[0] = 3.14; —— 那是未定义行为！
// 必须先 placement-new 构造：
for (std::ptrdiff_t i = 0; i < buf.second; ++i) {
    new (buf.first + i) double{0.0}; // 手动构造
}
// ……做计算
// ……排序、变换、归约
// 最后，显式析构（如果类型有非平凡析构函数）
for (std::ptrdiff_t i = 0; i < buf.second; ++i) {
    buf.first[i].~double();
}
std::return_temporary_buffer(buf.first); // 关键！必须还

这里藏着三个容易踩的坑，也是它被弃用的主因：
第一，它不保证返回请求长度——返回的 buf.second 可能小于你传入的 n，甚至为 0。这是它的“临时”属性：底层可能复用全局缓冲池，空间紧张就少给。你得习惯“借多少、用多少”，而不是“我要多少、就得多少”。
第二，它完全跳过对象生命周期管理——不构造、不析构、不拷贝。这意味着你面对的是 T*，但背后没有 T 的语义，只有字节。对 std::string 或 std::vector 这类类型，直接 get_temporary_buffer<std::string>(100) 是危险的，因为它们的默认构造成本高，且析构不可省略。
第三，return_temporary_buffer 不是可选操作——它不是“建议归还”，而是资源回收契约的一部分。漏掉它，缓冲池可能枯竭，后续调用全失败；跨线程调用更可能引发未定义行为（标准未规定线程安全性）。

那它还有存在的价值吗？有，而且很具体。
在实现自定义算法时，比如一个仅需临时数组做归并的 stable_sort 分支，或者图像处理中每帧申请几 MB 中间缓存——这些场景下，你清楚生命周期（函数内申请、函数尾归还），知道类型是 POD 或 trivially copyable，也接受“借不到就降级”的策略。这时 get_temporary_buffer 比 std::vector 少一次默认构造遍历，比 operator new 更贴近 STL 内部的内存策略，甚至比某些自定义 allocator 更轻量。

更值得玩味的是它的“哲学”：C++ 标准库从不回避裸内存操作，只是把它藏在足够深的地方。std::uninitialized_copy、std::uninitialized_fill、std::construct_at……这一整套工具链，才是 get_temporary_buffer 真正的搭档。它不是孤岛，而是一块拼图——拼上之后，你才真正看清“内存分配”和“对象构造”在 C++ 里是两件独立的事。

如今它虽已退出标准舞台，但不少 STL 实现（如 libstdc++、libc++）内部仍在用类似机制管理临时缓冲。读懂它，等于拿到一把解剖 STL 内存行为的解剖刀。下次看到 std::sort 在大数据量下突然变慢，不妨想想：它是不是也在某个角落，悄悄借了一块 buffer，又默默还了回去？

临时，不等于无用；退场，不等于过时。它提醒我们：C++ 的力量，常常藏在那些不声不响、却从不失约的底层契约里。