Ok no worries, thanks for the follow up! It was an interesting idea though.

I’ve just realized that there could be issues in returning a container of string_view; in particular, when you pass a temporary to the main function then the string_view(s) will result in something like dangling pointers.
So I think my suggestion was not so good, I’m sorry for that 🙁

Hey Stefano, glad to read you in the comments section! Hope I’ll hear of you more often here 🙂
Yes I think it makes sense to return a container of string_view. I’ll try to implement this, thanks for the suggestion.

It’s an interesting abstraction, and I think this leads to nice code indeed. So to implement the computation of the span (article that came out after your comment I think), we should make a separate traversal? This might not be a problem.

I agree that getWordsFromCode should be somehow private. The only external use I make of it is for unit tests, which I have omitted for brevity in the post series. But yes I agree with you.
Very cool idea to run in on the posts. FWIW, here is the word count for this post (code snippets included):

std             |        65
code            |        59
the             |        57
Words           |        50
of              |        41
is              |        39
Word            |        37
end             |        36
words           |        35
a               |        35
we              |        35

This can be extended by using templated functions split() in terms of 2 or 3 predicates – either delim pred and out preds or prefix, suffix and out preds. See http://coliru.stacked-crooked.com/a/297105d418051af4

This gives a rather nice ability to split like this

const string cw = "ThisIsAWordInCamelCase";
const string wrdtxt = "these are my words";
 
vector words;
 
split(begin(cw), end(cw), isDelimiter, isWord, [&](auto f, auto l) {words.emplace_back(f, l);});
split(begin(wrdtxt), end(wrdtxt), isDelimiter, [&](auto f, auto l) {words.emplace_back(f, l);});
copy(begin(words), end(words), ostream_iterator(cout, "n"));

Any thoughts?

Back to the words counter, since the code string you’re passing in to the main algorithm is immutable, what do you think about returning the result as a container of string_views? That should save both memory occupation and performance time; do you see any drawback using this approach?

A suggestion would be to have a stl type function with an interface that takes iterators and 1 or 2 unary predicates and returns a pair of iterators to the start/end of the extracted word. Either the same predicate is used for both before and after the word to be extracted – or one predicate is for before and one for after.

See http://coliru.stacked-crooked.com/a/dfbcbec6d31f15bd for an initial example of what I’m thinking. My thoughts are that having an stl-like function extract() is that, unlike split() etc, it doesn’t create/return a potential unwanted vector but just a pair of iterators to start/end of the word to be extracted. These iterators can then be used as needed (to add to a vector in the example case, or to update a map etc for word count). The returned end iterator, if not the end of the actual string being processed, then becomes the start iterator for the next extraction etc.

Note in the example I’ve changed the logic of isDelimiter().

Also I think this code could be applied to any form of text (for example this article!) since the delimiters are mostly universal. And it might be interesting to see what words YOU use in these articles. This might also suggest a name change from “…Code” to “…Text”.