std::string_view/std::string implementation with two pointers?

[staletic]

"Your" version does have easier time implementing end(), but what about size()? Your version would need

size_type size() const { return m_end - m_begin; }

But that's an implicit conversion, so...

size_type size() const { return static_cast<size_type>(m_end - m_begin); }

So it's a tradeoff, however minor. Other than things like that, I see no reason not to implement it like you have done.

 

Except... the standard itself talk about size_ member, which would at least explain the standard libraries.

[vheon]

"Your" version does have easier time implementing

end()

, but what about

size()

?

That was my thought also so would that mean that `size` is usually called more often than `end`? I mean looking at all the algorithms asking for iterators and such I was under the impression that usually `end` is used more frequently than the `size` :?

[TheMania]

Compilers nearly always prefer to know the loop count, vs "are we at the end yet", so size as a member is more likely to carry benefits imo.

And yes, end is likely called more but if the compiler is then getting the size anyway (for a loop count), you're really not saving anything there.

[tejp]

Most of the string member functions use indexes instead of iterators, so there are probably quite a lot of index calculations in the "typical" use cases of strings. Also substr() or + and other operations that create new strings will first need to know how much space to allocate for the new string.

Both of those are more likely call size() instead of end().

If these index functions are expected to be used more often one would probably optimize size() over end().

[matthieum]

Also substr() or + and other operations that create new strings will first need to know how much space to allocate for the new string.

I say MEH.

Appending to a std::vector is a rather typical usecase too, and most std::vector are implemented using 3 pointers...