[zl4000]

No that's BS. `std::string` should be used where ever it is applicable.

The whole issue that this post about chrome was talking about was dealing with a poor usage of `std::string`, such as passing c_str() to then go and construct another string instead of passing by const ref.

Or building a set of `std::string` to simply check if a value exists.

That's just shit code, not an issue with `std::string`.

[humanrebar]

There's a right way to do it. It's not the obvious way. Berating people for coming to terms with that isn't helpful.

It's not their fault that C++ only really supports std::string out of the box. What are the alternatives?

1. const std::string & : what if I have a vector<char>?

2. const char * : what if it's not null terminated?

3. const char * and size_t : Better, but what if I have a deque<char>?

4. const char * start, const char * stop : Better because you can write algorithms around this, but still, doesn't help with deque<char>?

5. template on START_ITER and STOP_ITER : The best we have now if you need an extremely general solution. But I hope writing your implementation in headers is fine.

6. home grown type : a very popular choice, but http://xkcd.com/927/

7. boost::string_ref : maybe the best choice, as it can be created from 1-4 (and most 6's), but still doesn't work with deque<char>.

...so give the rookie a break. But I'll support any comment in a code review about not accepting std::string by reference or by value in an interface.

[nightcracker]

#5 and many, many other reasons is why C++ desperately needs a standardized range type. Let's pray it comes in C++17.

[pja]

What would a range type offer over a pair of iterators?

[humanrebar]

cout << takeFirstN(sort(myVector), 10) << '\n';

...try that with iterators.

[vegancap]

Right, I guess I misunderstood the article. As I said, new to C++.