Table of Contents
Profile
Understanding String (basicstring)
About TempString base Classes
Source
Reference reading
Profile
As we know, the C + + standard library (STL) provides string manipulation by the Basic_string class. The string is most likely to use the most frequent STL class in addition to the memory allocator (allocator) 1. But the C + + community's accusations of string have never stopped.
To sum up, the STL string class mainly has the following points of contention:
There are too many interfaces and there is no good consistency between specifications and other STL containers. For example, String::find uses subscript instead of iterator as an iterative position, which is not the same as other containers.
Memory fragmentation. The memory fragmentation of the system is serious due to too frequent string constructs and destructors.
Copy-on-write and multithreading security. String (basic_string) is based on Copy-on-write technology because the assignment of string is designed to be low overhead. But once multithreaded security is taken into account, Copy-on-write spends a lot of time spending on locks. Some new STL implementations, such as the SGI STL, discard string implementations based on Copy-on-write.
I agree with these accusations. The best design for a string is to split the string into a constant string (std::string) and a string manipulation class (StringBuilder). Our Stdext library has done so.
Understanding String (Basicstring)
Stdext string (basicstring) is different from all the string classes you've seen before. This analogy, as you can imagine, is simple, it has only two member variables:
template <class _E>
class BasicString
{
const _E* m_pszBuf;
size_t m_length;
};
It differs from string (basic_string) Where:
It is a constant string, and it never attempts to tamper with the string content (M_pszbuf point to the data).
It's not destructor, you can think of it as a structure. Of course, for convenience, Basicstring still has a constructor.
Its m_pszbuf does not end with nil. Instead, the length of the string is qualified by the M_length member.
It does not maintain the life cycle of string content (M_PSZBUF). As mentioned above, it is not destructor, and at any moment it simply accepts or generates string content, but is not responsible for destroying it.
The last point is very important and it is special: it does not maintain the life cycle of strings. This may surprise you: there is such a string class, it does not manage the life cycle of strings.
But we did it. And it does bring us a lot of convenience. For example:
Assignment (copy), substring (substr) is a very lightweight operation. The Copy-on-write technology is completely redundant.
Arbitrary linear containers (such as std::vector, std::basic_string) can be temporarily converted to string (very lightweight). See the introduction to the String::cast method below.
Why can a string class not manage its own lifecycle? This is the idea of our Stdext memory Management change initiative.
To browse the reference manual for the string class, you notice that there are two constructors:
BasicString(const value_type* pszVal, size_type cch);
template <class AllocT>
BasicString(AllocT& alloc, const value_type* pszVal, size_type cch);
This means that the first constructor passes in the Pszval, whose life cycle is longer than basicstring (still valid until Basicstring destructor). The second constructor means that Pszval is a temporary, valid string that copies a pszval string.
Why don't you support constructs such as basicstring (const value_type* pszval)?
It's simple, the construction is too dangerous, I'm not sure what your intentions are.
About TempString base Classes
In a literal sense, this is a temporary string class. Why is it the base class for string (that is, basicstring)? This is really just the need to achieve. TempString is, in theory, string (just a special life cycle), consistent with the basicstring specification. The reason why it finally becomes the base class of basicstring, is completely convenient to realize the consideration.
Taking Basicstring::compare as an example, we examine the following function:
int BasicString::compare(const TempString<_E> b) const;
The meaning of this function is very rich. This is equivalent to defining the following series of functions:
int BasicString::compare(const _E& b) const; // 与包含单个字符b的字符串比较
int BasicString::compare(const _E* b) const; // 与C Style风格的字符串b比较
int BasicString::compare(const basic_string<_E>& b) const; // 与STL string比较
int BasicString::compare(const BasicString<_E>& b) const; // 与另一个常String比较
int BasicString::compare(const vector<_E>& b) const; // 与向量表示的字符串b比较
int BasicString::compare(const BasicStringBuilder<_E>& b) const;
A function can be up to 6 functions!