针对你提到的痛点——原写法语法繁琐、宏UINT64_C类型不符合预期的问题，结合C++标准和无符号类型的限制，给你推荐几种靠谱的方案：

• 直接使用std::uint64_t显式初始化（C++11及以上）
  这种写法语义最直接，完全规避宏的不确定性，而且是编译期可计算的常量：

  #include <cstdint>
  
  constexpr std::uint64_t v = std::uint64_t{1} << 32;
  

  解释：用列表初始化std::uint64_t{1}明确把1转换成目标类型，再进行移位操作。无符号类型的左移只要移位位数小于类型位宽（这里uint64_t是64位，32<64），行为完全符合标准，不会出现未定义问题。

• 自定义字面量简化写法（C++14及以上）
  如果觉得每次写std::uint64_t{}麻烦，可以自定义一个字面量后缀，让代码更直观：

  #include <cstdint>
  
  constexpr std::uint64_t operator"" _u64(unsigned long long val) {
      return static_cast<std::uint64_t>(val);
  }
  
  // 使用起来非常简洁
  constexpr std::uint64_t v = 1_u64 << 32;
  

  解释：自定义的_u64字面量会把输入的无符号长整数直接转换成std::uint64_t，一眼就能看出常量的类型，而且编译期就能完成计算，完全满足constexpr要求。

• 兼容老版本的constexpr函数封装
  如果需要兼容C++11之前的版本（或者习惯用函数明确语义），可以封装一个简单的constexpr函数：

  #include <cstdint>
  
  constexpr std::uint64_t make_uint64(unsigned long long val) {
      return static_cast<std::uint64_t>(val);
  }
  
  constexpr std::uint64_t v = make_uint64(1) << 32;
  

  解释：函数名make_uint64清晰表达了转换目的，比直接写static_cast语义更明确，同时避免了宏UINT64_C带来的uint_least64_t类型问题。

无符号类型相关注意事项 #

• 移位操作时，移位位数必须小于目标无符号类型的位宽（比如uint64_t是64位，移位位数要<64），否则行为是未定义的；
• 始终用无符号数作为移位的源值，避免用有符号数（比如1默认是int，虽然这里转换后没问题，但养成习惯能避免有符号数溢出的未定义行为）。

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