【发布时间】:2022-11-14 05:18:02
【问题描述】:
问题是我不明白为什么这些应该分开。为什么不使用一个类,比如 CharType,它同时包含 char 特征和 char 类型的逻辑。 我的意思是替换:
template <class _Elem, class _Traits = char_traits<_Elem>, class _Alloc = allocator<_Elem>>
class basic_string { /*...*/ };
接着就,随即:
template <class ExtendedTraits, class _Alloc = allocator<_Elem>>
class basic_string { /*...*/ };
其中 ExtendedTraits 是 _Elem 和 _Traits 的预设组合,可能如下所示:
template<_CharType> //all the necessary template parameters
class extended_traits
{
public:
using value_type = _CharType;
private:
_CharType _elem;
public:
//... all methods, that used to be in char_traits but now non-static and accepting one parameter
};
我尝试实现这两种方法,它们都有效,但可能有一些我仍然没有注意到的问题。
【问题讨论】:
-
你更喜欢看什么,
basic_string<char>或basic_string<extended_char_traits<char>>? -
如果要追溯
basic_string的历史和血统,几乎可以肯定我们会发现char 类型排在第一位,并且为了保持向后兼容性,添加了traits 类型作为附加的默认模板参数与现有代码。 -
char特征可以已被假定和引用,而不是让它们成为具有默认值的参数。但是它们不能因为(比如说)需要具有不同特征的char而变化。很可能原来的string就是这样做的(参见 Sam 的评论)。 -
实际上确实有匹配
_Elem的Traits::char_type(以及分配器的value_type) -
我认为这是有道理的,我想要一个
char的容器,特征和分配器只是它的补充。
标签: c++ stdstring char-traits