C++用户定义字面量怎么用

operator""是C++11引入的用户定义字面量运算符，仅对编译期字面量（如42_km、"abc"_sv）生效，不作用于变量或运行时值；需按字面量类型（unsigned long long、long double、const char*+size_t）重载，且必须inline定义以防ODR错误。

什么是 operator""，它到底在哪儿生效

用户定义字面量不是宏，也不是函数调用，而是一个编译期触发的重载运算符——operator""。它只对字面量（如 123、"hello"、3.14）起作用，对变量、表达式或运行时构造的值完全无效。

常见误用：试图给 int x = 42; auto y = x_km; 这类写法加后缀，结果编译失败。因为 x 是变量，不是字面量，operator""_km 根本不会被考虑。

• 42_km ✅ 可行（整数字面量 + 自定义后缀）
• 42.0_km ✅ 可行（浮点字面量，需对应 long double 版本）
• "abc"_sv ✅ 可行（字符串字面量，C++14 起支持）
• std::string("abc")_sv ❌ 不会触发，类型已确定为 std::string

怎么写一个安全的长度单位字面量 _km

目标是让 123_km 返回 std::chrono::duration 或自定义 Distance 类型，但必须注意字面量类型推导规则和常量表达式限制。

关键点：整数字面量默认是 unsigned long long（除非带符号前缀），浮点字面量默认是 long double；字符串字面量传入的是 const char* 和 size_t 长度。

• 写整数版必须用 unsigned long long 参数，不能用 int 或 long，否则不匹配
• 若想同时支持 1.5_km，得额外定义 long double 版本，且返回类型需能隐式转换或保持一致
• 返回类型必须是字面量类型（constexpr 构造、无虚函数、无非静态成员指针等），否则无法用于模板非类型参数或 constexpr 上下文
• 示例：

  constexpr Distance operator""_km(unsigned long long km) { return Distance{km * 1000}; }

字符串字面量 _sv 为什么比 std::string 更轻量

"hello"_sv 通常返回 std::string_view，它不分配内存、不拷贝字符，只存两个指针（const char* + size_t）。而 std::string("hello") 每次都触发堆分配（除非短字符串优化触发，但不可靠）。

但要注意：字符串字面量生命周期是静态的，所以 operator""_sv 返回的 string_view 安全；可一旦你试图从局部数组构造字面量（比如 char buf[] = "hi"; auto sv = buf_sv;），就根本无法编译——因为 buf 不是字面量。

• 合法："data"_sv → 编译器知道地址和长度，constexpr 友好
• 非法：char s[] = "x"; s_sv → s 是局部变量，不能作为字面量参数传递
• 兼容性：C++14 引入字符串字面量运算符，C++17 起 std::string_view 成为标准，但老编译器需自己实现轻量 view 类型

容易被忽略的链接与内联问题

所有 operator"" 必须声明为 inline 或放在头文件中定义，否则跨 TU 使用会报 ODR（One Definition Rule）错误。这是因为字面量运算符是隐式 extern 链接的，而多个翻译单元里同名未 inline 的定义会被视为冲突。

• 不加 inline：在 A.cpp 定义 operator""_ms，B.cpp 也用 100_ms → 链接时报 duplicate symbol
• 正确做法：头文件中直接定义，或加 inline constexpr（C++17 起推荐）
• 模板化字面量（如 operator""_i<3>）可绕过部分 ODR 限制，但实用性低，且 MSVC 对其支持较晚
• 调试时发现字面量没进断点？大概率是编译器在常量折叠阶段就替换了，实际没调用函数体

最麻烦的其实是混合使用：比如一个库导出 operator""_url，你自己也定义了同名的，但没加 inline，链接时静默选错版本——这种问题很难定位，因为错误不报在定义处，而在链接或运行时行为异常。