std::destroy_at主流编译器行为差异及标准合规性问询

该现象属于对C++标准规则的理解偏差，代码本身不存在可移植的确定行为，MSVC的输出完全在标准允许的合规范围内，既不是MSVC的标准符合性问题，也不是编译配置错误；GCC、Clang能触发自定义特化属于实现巧合，并非标准强制要求的行为。

• C++标准仅允许在满足两个前提时向std命名空间添加模板显式特化：一是特化依赖的类型为用户自定义类型，二是特化完全符合原模板的语义要求。但即便满足这两个前提，标准也不保证标准库内部逻辑一定会调用用户特化的std::destroy_at版本。
• std::destroy_at属于标准库的可定制点对象（niebloid），从C++20开始，标准明确允许实现将这类工具实现为不可被用户特化的函数对象，而非普通的可特化函数模板；同时标准仅规定标准库组件的对外语义，完全不限制内部实现逻辑——比如std::shared_ptr销毁托管对象时，既可以调用公开的std::destroy_at，也可以直接调用析构函数，或者调用内部私有的销毁辅助函数，所有实现方式均合规。

• 测试所用的GCC、Clang版本中，std::shared_ptr的控制块销毁逻辑恰好调用了公开的std::destroy_at函数模板，且该版本实现将destroy_at定义为可特化的普通函数模板，因此用户写的特化能被正常匹配调用。
• MSVC v19.32的实现中，std::shared_ptr销毁托管对象时没有走公开的std::destroy_at入口，而是直接执行析构逻辑，自然不会触发用户编写的特化版本，该行为完全符合标准要求。

如果需要自定义类型的销毁逻辑，直接为类型编写符合语义的析构函数即可；如果需要针对shared_ptr场景定制销毁行为，应当在构造shared_ptr时传入自定义删除器，不要通过特化std::destroy_at的方式实现，该方式不存在可移植性保证。

测试代码 #

#include <iostream>
#include <memory>

struct test
{
  test(int i)
  {
    std::cout << "test::test("<<i<<")\n";
  }
  ~test()
  {
    std::cout << "~test()\n";
  }
};

template<>
void std::destroy_at(test* p) 
{
  std::cout<<"std::destroy_at<test>\n";
  p->~test();
}

int main ()
{
  auto sp = std::make_shared<test>(3);
  return 33;
}

各编译器测试输出 #

GCC/Clang（x86-64） #

Program returned: 33
test::test(3)
std::destroy_at<test>
~test()

MSVC v19.32（x64） #

Program returned: 33
test::test(3)
~test()

内容的提问来源于stack exchange，提问作者Raymund Hofmann