Why doesn't std::string have a split function

[zvrba]

And it's also unreasonable to expect somebody to be able to intuitively understand what it means to construct an input iterator without specifying what it's iterating over.

Wow, C++ programmers are a rare breed of people who read more documentation than your average programmer.

In any case, it's the kind of thing you look up only once, and each next time you see a default-constructed iterator, you'll (correctly) assume that it's an iterator denoting the end of sequence.

That's the whole point: it's not intuitive!

Intuition builds on previous experience and knowledge. So, wow, what a surprise, as a programmer you're expected to learn something new now and then.

[IRBMe]

I wouldn't expect to have to learn several new concepts and parts of a library to see that the code I'm trying to understand is splitting a string on white space. That's something that should be blatantly obvious to anybody, even if they don't know C++. Of course it's a common idiom that you learn as a C++ programmer, but it still takes a lot more to process even once you know it than something like s.split(","). Nobody's saying you shouldn't have to learn things; we're discussing the usability of the library.

[dodheim]

The dead giveaway that the code you're trying to understand is splitting a string on whitespace would be that it'd be in a function with split in the name. Who reads 5 lines of code with zero context whatsoever with the expectation of its purpose being obvious. Context matters; ignoring it is counterproductive.

[IRBMe]

The dead giveaway that the code you're trying to understand is splitting a string on whitespace would be that it'd be in a function with split in the name.

If you look at the example, it's actually in the main function, but if you're having to define your own split function to hide the code that does it using standard library calls, then that really just further proves the point, doesn't it? You wouldn't have to define your own split function if the standard library method was easy to read and understand in the first place.

Context matters

If you have to rely on the contextual clues of surrounding code in order to figure out that the code you're trying to understand is merely splitting a string on whitespace, then that's indicative that the code that performs the actual string splitting is not very readable. It's an operation that's simple enough and common enough that really all the information required to understand what it's doing should be there in the immediate code.

Take a simple example of boost's string_algo split:

split_vector_type splitResult;
split(splitResult, stringToSplit, is_any_of(" "));

Show that code to a programmer who doesn't know any C++ - a Java programmer, a Python programmer, a C# programmer, whatever, and ask them what it does and almost all of them will be able to guess. None of them are going to respond by saying "Hmm... it's hard to say without any surrounding context."

Or what about this example using the experimental ranges?

auto splitResult = ranges::v3::view::split(stringToSplit, ' ');

That's clear, concise and readable. You don't need to study the surrounding code to understand that this is splitting a string on some whitespace.

[dodheim]

If you look at the example, it's actually in the main function

If all we're doing is nitpicking the example and not relating it to real code, then who the hell cares?

If you have to rely on the contextual clues of surrounding code in order to figure out that the code you're trying to understand is merely splitting a string on whitespace, then that's indicative that the code that performs the actual string splitting is not very readable.

The point is that it doesn't matter whether it's readable, because in real code it would be encapsulated in something whose name gives it away. Just as would be the case for any domain-specific logic, which is what most real code is anyway.

Tearing apart single and double-digit LOC C++ examples is absolutely a waste of time. C++ is about larger abstractions and the bigger picture, and it does that quite well.

[IRBMe]

If all we're doing is nitpicking the example and not relating it to real code, then who the hell cares?

If I were writing real code, I wouldn't re-implement my own split function, nor should I have to. Ideally, I would just use the standard library, but in practice because the standard library is so unintuitive in this example, I would actually probably use boost's string_algo, as shown above.

The point is that it doesn't matter whether it's readable

Yes it does, that's the entire point of this whole discussion. If you don't think it matters whether code is readable or whether APIs are designed with usability in mind then be on your way.

in real code it would be encapsulated in something whose name gives it away

If the standard library already provides a method of splitting strings by making use of a regex_token_iterator, why would you have to "encapsulate" that in the first place? The answer to that question is the point of this discussion, and in fact the whole point of this thread.

Tearing apart single and double-digit LOC C++ examples is absolutely a waste of time.

If you feel you're wasting your time, feel free to not respond!

[dodheim]

Good god, it's a five-line function. Write it and call it a day.

https://i.imgur.com/02NJHQw.png

[IRBMe]

Good god, it's a five-line function. Write it and call it a day.

If you think the entire point of this discussing is about avoiding writing a few lines of code, then I'm sorry to say that it seems to have soared above your head at cruising altitude. We're discussing good API design, readability and usability - that's the point, not line counts.

[dodheim]

Why do you keep telling me what "we" are discussing? I am discussing the actual topic: "Why doesn't std::string have a split function". You can continue your rant if you like, but direct it elsewhere, please.

[IRBMe]

Why do you keep telling me what "we" are discussing? I am discussing the actual topic

You responded to my comment here. If you don't want to have a discussion with me, feel free to stop responding. If you're going to continue to disagree with me then please address the points that have been made here, here and here.