c++ - 为什么 `std::align_val_t`要限制隐式转换?

标签 c++ interface new-operator software-design memory-alignment

std::align_val_t 限制隐式转换:

// won't compile
// std::align_val_t align = 64;

auto aln = std::align_val_t{64};

当我的代码对齐时,我应该在我的界面中保留这个隐式转换的限制吗?

允许将 size_t 参数隐式转换为 align_val_t 是一种好习惯吗?

例如:

[[no_discard]] T* make_copy_on_heap(const T (array&) [N], std::align_val_t aln )

对比

[[no_discard]] T* make_copy_on_heap(const T (array&) [N], std::size_t aln )

如果我允许后者(size_t 接口(interface)),为什么 std::align_val_t 首先要限制隐式转换?

最佳答案

align_val_t 是一个强类型枚举,它们不允许与整数之间的隐式转换。

align_val_t 从一开始就是一个 hack -- 该类型的存在只是为了防止与其他常规参数混淆。

关于c++ - 为什么 `std::align_val_t`要限制隐式转换?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51463113/

相关文章:

delphi - 如何获得已弃用的接口(interface)函数以停止显示编译器警告?

c++ - 了解在共享库中重载 operator new 的行为

c++ - 如何将 key 发送到当前从后台程序运行的任何应用程序 (c++)

c# - 我可以在 C# 中创建使用未知类型参数声明方法的接口(interface)或抽象类吗?

c++ - 使用成员函数模板实现接口(interface)的函数

c++ - 尝试删除字符数组时崩溃

pointers - Golang 使用 New() 返回结构指针而不是直接创建一个

无法识别类模板的 C++ 成员函数

c++ - std::array<> 是否只保证在堆栈上分配?

c++ - 寻求帮助将 SOLID 原则应用于文件 I/O 问题