对分配器返回的指针执行指针运算是否合法？C++17与C++20中的规则差异及前置构造场景分析

这问题问得相当精准，直击C内存模型里最容易混淆的细节之一！咱们结合C标准的演变，把这个问题拆解得明明白白：

先给你核心结论 #

• C++20及以后：你说的先构造mem[1]而非mem[0]的场景完全合法，不属于未定义行为（UB）；分配器返回的指针，只要指针运算结果落在分配的内存范围内（包括尾后指针），都能安全执行，和对应位置有没有构造对象无关。
• C++17及之前：标准规则确实有点模糊，但实践中所有主流编译器都支持这种操作（毕竟std::vector这类标准容器的实现根本离不开它），通常不会被视为UB；后来的P0593提案就是专门用来澄清这个模糊点的。

详细拆解细节 #

1. 分配器返回指针的本质 #

当你调用allocator_traits::allocate(allocator, 10)拿到T* mem时，这个指针指向的是一块连续的、专门为10个T类型对象预留的原始内存——划重点：此时这块内存里没有任何T对象，只是具备存储T的条件而已。

2. C++17的模糊地带 #

在C++17及更早的标准里，关于指针运算的规则描述得不够明确：标准要求指针运算的操作数必须指向“数组对象的元素”或者数组的尾后位置，但这里的“数组对象”到底算不算未构造对象的原始连续存储？

实践中，所有主流编译器都默认这种原始连续存储可以被当作“逻辑数组”来做指针运算，不然std::vector里类似newbuf + size()的代码（计算已构造对象的尾后位置，哪怕后面还有未构造的预留空间）根本没法合法工作。但严格来说，标准当时没把这一点说死，才导致了你提到的那种有争议的观点。

3. C++20的明确规则（P0593提案） #

P0593提案直接把这个模糊点彻底澄清了，它重新定义了C++的对象模型，明确区分了“存储”（storage）和“对象”（object）：

• 当分配器给你分配了能容纳N个T的连续存储时，这块存储本身就构成了一个连续的存储序列，哪怕里面一个T对象都没构造。
• 指向这个存储起始位置的T*指针，可以被看作指向这个存储序列“第一个元素位置”的指针，这时对它执行mem + i（0 ≤ i ≤ N）的指针运算完全合法，不管mem[i]位置有没有构造T对象。

说白了，你听到的“storage + i需要前置元素都构造”的观点是错的——P0593明确了指针运算只看存储的连续性，和对象有没有构造半毛钱关系都没有。

4. 构造mem[1]的合法性 #

既然mem + 1的指针运算合法，那调用allocator_traits::construct(allocator, mem+1, params...)在这个位置构造对象就完全合规：

• mem+1指向的是一块适合存储T的未使用存储位置；
• construct的本质就是在指定的原始内存上初始化T对象，只要这块内存适合放T，就没任何问题。

哪怕你永远不构造mem[0]，也不会影响mem[1]处对象的合法性——唯一要注意的是，你之后不能访问mem[0]（因为那儿根本没有对象），但构造mem[1]这件事本身绝对安全。

最后再划一遍重点 #

• 只要指针运算的结果落在分配器分配的内存范围内（包括尾后指针），不管对应位置有没有构造对象，都能安全执行；
• C++20通过P0593彻底解决了之前的模糊问题；
• 你给出的代码在C20里完全合法，C17里实践中也没问题，不属于未定义行为（UB）。

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