Is std::string size() a O(1) operation?

问题:

Is std::string size() a O(1) operation?

The implementation of STL I'm using is the one built into VC++

回答1:

If you're asking if MSVC's implementation of string::stize() has constant complexity, then the answer is yes. But Don Wakefield mentioned Table 65 in 23.1 of the C++ Standard where it says that the complexity of size() should follow what's said in 'Note A'. Note A says:

Those entries marked ‘‘(Note A)’’ should have constant complexity.

However, that does not mean that those entries shall have constant complexity. Standards use very specific terminology, and "should" means it's not required.

'Note A' was added to the standard specifically to appease those who believed that size() should be allowed to have linear complexity so there would be no need to maintain the size when containers were modified.

So you can't rely on size() having constant complexity, but I'm honestly not sure if there are any implementations that do not have a constant string::size().

回答2:

Here's an easy way to answer that question for msvc++.

Write some code in a project:

string happy;
happy.size();

Hilight the .size call, right-click, go to definition.

On my install (vs2005sp1) this sends me to xstring:1635, which looks like this:

size_type __CLR_OR_THIS_CALL size() const
    {   // return length of sequence
    return (_Mysize);
    }

So it looks like the string has a member called _Mysize, and it's just returning that.

In other words, this is a O(1) implementation.

回答3:

Yes, std::string::size() is O(1).

回答4:

See Table 65 in Section 23.1 of the Standard. "a.size()" is listed as "(Note A)", which says that "Those entries ... should have constant complexity".

Section 21.3 says that strings conform to the requirements of a sequence (23.1), ipso facto, size() is constant time.

回答5:

For a string, the size() operation has to be constant for all string implementations that don't use ropes⁽¹⁾. There is no explicit requirement in the standard that requires the operation to be O(1), the closest is the generic requirement that size() should be constant time, but that leaves room for any other complexity measure.

So why must it be O(1)?

This comes from the fact that the size cannot be calculated from the contents of the string itself. While in C you use a NUL terminator to determine the end of the string, in C++ NUL is as valid as any other character in the string. Since the size of the string cannot be calculated from the contents⁽²⁾, it must be handled externally, independently of the actual size of the string.

⁽¹⁾ C++03 standard allows an implementation to use ropes as the implementation for strings, but the fact is that none of the current implementations of the standard libraries use them.

⁽²⁾ If the implementation used ropes, the operation could depend on the size by means of the number of blocks from which the rope was constructed if the blocks were linked through a linked list or similar construct, or if they were allowed to have different sizes. But ropes are not used in any standard library implementation that I know of.

回答6:

Performance is guaranteed by the STL to be at least O(N) for containers, however many containers including std::string can implement this as O(1) and will. Usually it'll either return a simple variable or do something like _End - _Begin and return that.

回答7:

size_type __CLR_OR_THIS_CALL size() const

{   // return length of sequence

    return (_Mysize);

}

So it eventually might be like this, but you can never be sure.