假设我写了一个类似于static_string的类型（只是一对size_t和N个字符，其中N是template int参数）。因此，可以安全地复制我的类型，而无需运行析构函数。但是它具有用户提供的副本构造函数，因此C ++语言不会将其检测为普通副本。
我想告诉我这种类型的用户，他们可以复制我的类型，并且不需要运行析构函数。
我一直以为我可以专门研究type_traits，但是最近我才知道这样做是UB。
如果无法使用traits类型来做到这一点：C ++ 20中是否有一个命名概念可以满足我的类型的要求，至少在注释中我可以用它代替单词？
P.S。我知道编写这样的类型是一个坏主意，但是存在一些用例：优化，共享内存（您不希望字符串堆分配alloc）。
因此可以安全地复制我的类型，而无需运行析构函数。但是它具有用户提供的副本构造函数，因此C ++语言不会将其检测为普通副本。
这是一个矛盾。就C ++语言而言，如果您的类型不是TriviallyCopyable，则它不是“安全存储”的。如果memcopying等效于副本，则必须表示复制对象相当于memcpy。如果两个操作相同，则它们必须相同。
[在不牺牲其中一个的前提下，无法解决这一矛盾。要么使所有复制等效（memcpy和复制构造函数/赋值），要么不允许memcpy。
问题是：与仅复制在复制构造函数/赋值运算符中实际具有值的字符的优化相比，平凡的可复制性有多重要？不能同时拥有。就我个人而言，我要说的是静态字符串绝不能过大，以至于仅复制整个内容的成本就具有至关重要的意义。并且在实际上很重要的极少数情况下，提供专门的功能来进行复制。
[我确实发现区分mem*类型是有益的，在这些类型中，函数可以仅使用推土机在不同类型的C ++类型上使用C型派系进行字段复制，而没有副作用。我使用“ C”源文件作为区别因素。也许您可以使用命名约定或类似的名称。
尽管我个人还是这样区分C和C ++，例如与.HPP相反的标头的.H扩展名，.CPP反对的.C源文件。
我确实找到了最佳位置。就像我只想在限定符中使用带有限定符的C ++时被迫使用C或C ++。但是在实践中，我只是将C和C ++代码分开...像比理想情况更多的分离/隔离，但是它使事情保持整洁有序。
对于C ++，如果您想使用最通用的泛型类型，我认为实际上我们不得不在效率上做出妥协，或者花一年时间在无休止的用户响应和调整之后为boost.lib做出贡献。我对后者没有耐心，所以我只是将C库/ API与C ++库/ API分开。 C语言要求我付出比我想要的更多的折衷，但是他们提供了我绝对想要的保证。
C ++类型系统的灵活性和丰富性是IMO的最大弱点之一。即使是实现标准可迭代且可移动构造的单链列表类型，也并非没有轻而易举。这既是C IMHO的优点也是缺点。 C有一个哑系统。除非程序员和设计人员提出进一步的要求，否则您可以将其类型看作主要是位和字节来移动和复制。这不仅仅是国际海事组织的弱点。这既是一个弱点，也是一个优点。