Hacker News Reader

Comment by mehrdadn | Hacker News Reader

I say this with a lot of love for C++, and I think it has gotten much better, but just try splitting a string via another string as the delimiter...

View on HN

My favorite weapon of choice for this is absl::StrSplit. It can be very efficient because it adapts to any return type you like (including range types, so you can `for(string_view : StrSplit()) {...}`).

To be fair this is not a problem of the language but a library problem.

I'm not sure whom/what this is being fair to, given both of these are specified by the C++ standard, but sure.

And the fact that libraries are still a pain point in C++ is a language problem.

Why would that be more difficult in C++?

Because it doesn't even exist as provided functionality; you have to code basic stuff like this yourself. See for example https://stackoverflow.com/a/14267455

It is possible with a regex iterator

  #include <iostream>
  #include <regex>
  #include <string>

  int main()
  {
   std::string s = "Python*C++*Java";
  std::regex regex("\\*");

  std::vector<std::string> out(std::sregex_token_iterator(s.begin(), s.end(), regex, -1), std::sregex_token_iterator());

  for (auto &s: out) {
    std::cout << s << '\n';
   }

  return 0;
  }

Hey just curious i have only coded c++ in school I’m curious to know why don’t we use `using namespace std;` in real world when writing c++

Because it imports literally everything into your current scope, and the standard library types are named in such a way that they will likely conflict with code you write. Named a variable “min” or “max”? Function called “list”? You’re going to cause problems for yourself.

Plus, using std:: is generally a good reminder that you’re using the standard library types and not some homegrown facsimile of that type, as is common in many C++ projects.

Because it imports everything from the std namespace and can lead to name clashes. It also makes it harder to see where symbols come from. If you see `std::vector` you know exactly what it is. If you just see `vector` in a large code base it could be anything. Could be a hand-rolled version of std::vector from prehistoric times or people not trusting the STL for no reason. Could also be a mathematical vector or something for vector graphics or whatever else. That is why people generally always fully specify where things come from, it's not limited to just the STL.

`using namespace X;` is somewhat fine if you limit it to a scope by using it in a source file and ideally only the function body where you use it, in header files it is a really bad idea because then the namespace gets exposed to everything including that header. That can lead to the compiler calling the wrong function and you might not even notice it.

In addition to the other comments (which are the primary reasons), beware that you can actually get different behavior due to something called "argument-dependent lookup". The most well-known example being std::swap(a, b). In general it is not equivalent to using namespace std; swap(a, b), though in this case, you actually want to say something else (using std::swap; swap(a, b)) to avoid importing the entire std namespace while also ensuring you call the ADL version of swap that may have been provided.

Stop

This is my annoyance with C++, it feels like the effort put into the language is disproportionate. As in, the committee is off solving problems that a handful of library implementors will use, but basic things like splitting strings or trimming whitespace is ignored. Yes these are fairly trivial but you either roll them over and over or start carrying around a little utility library.

After having used both Python and C++ for a while I concluded that most of the problems of C++ could be solved by a proper standard library.

Beh, it's one function call if you use Qt or boost

Difficult, probably not.

Verbose and clunky and needs a web search to do, yes.

I'm guessing it's analogous to Java's Regex. Like, yes, they're there and do as much as any other language, but lord it's a PITA.

It is not difficult to do it, but it is difficult to do right and in a C++ way. That means with least overhead, i.e. not copying stuff if not necessary and not doing any memory allocations. This is why C++ still has no string split is its standard libary: People cannot agree how it should look like.

There is, however, boost::split from the famous boost library.

Do you know if they're revisited this ever since string_view was implemented? I feel like a vector<string_view> should be quite uncontroversial, and you could even propagate the allocator from the string to the vector.

Since they now have ranges, the discussion can start all over... But I'm maybe no completely up to date, where the discussions is.

With range it would be

    auto splitText = text | view::split(' ') | ranges::to<std::vector<std::<wbr />string>>();

It should return a range of string views, no allocation is necessary.

That sounds like a great idea. Not sure if it might present a bit of a hurdle if the caller prefers it to be random-access, but I'm kind of tempted to try this out and see if it might present issues in practice. It might be worth suggesting it to the standards committee?

I think it should be bidirectional. Random access is expected to mean O(1) advancing of the iterator. I don't think it can be done without upfront work and allocation at construction.

If one needs random access they can always do the bidirectional range -> vector of string_views conversion.

Ranges are relatively new in the standard and not many algorithms landed in the library. I'm pretty sure there will be many new range algorithms in the upcoming standards. This particular algorithm is probably worth suggesting. I recommend floating the idea on the cpplang slack (there are #ranges and #future_standard channels) and/or the std-proposals mailing list. I never wrote a proposal, but you can chat with people who did.

https://cpplang.slack.com/

You can get an invitation here: https://cpplang-inviter.cppalliance.org/

https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

In C++ you can implement it in a way that gives you much more control.

Do you want to truncate the string? return new strings? return string views? It all depends what you need.

In some languages all strings are immutable and all operations result in new strings and you have no control over that.

The trouble is often it doesn't matter and literally any of those would be useful, and yet none of them exists for you to use, so you have to waste time reinventing the wheel.

Perhaps they're not in the standard library, but they're readily available on Boost, POCO and many other well known mature libraries.

Check the Boost C++ string algorithms library.

https://www.boost.org/doc/libs/1_74_0/doc/html/string_algo/u...

Is there any language where string handling doesn't suck? (No script languages please, because they cheat by implementing the hard things on C or C++)

From memory the less horrible experience i had was with Go, but there's help for the slices on the runtime which let the difficult parts hidden and also the batteries-included std library, which is one of the most well designed standard libraries out there.

Buffer management is one of the things that sucks the most in any language, and the ones that dont its because the complexity is hidden in another fundamental layer.

I think it's pretty nice in Scala. I don't know if "no virtual machines" was implied as part of the "no script languages" request, though.

  scala> "Mary had a little lamb. The lamb was in federal witness protection.".split("lamb") 
  res0: Array[String] = Array("Mary had a little ", ". The ", " was in federal witness protection.")

No, its ok and not part of that category.

I meant for languages where the hard parts are delegated to another like Python and Javascript (C and C++ respectively).

C# and Python...

  "a, b".Split(", ")  // C#
  "a, b".split(", ")  # Python

In Rust:

    "a, b".split(", ")

I would risk to mention Tcl as a good candidate, which might be unfair because the language is designed for strings.

  split "foo.bar" .
    => foo bar

> implementing the hard things on C or C++

This misses the point. I don't care how the language implements the functionality if it meets my performance requirements and it is convenient to use.

> This misses the point. I don't care how the language implements the functionality if it meets my performance requirements and it is convenient to use.

I dont think it does, because it meant you are working on a simple language that can only afford to be simple delegating the harder parts to other languages that took the effort to be designed to deal with everything.

The convenience is payed by someone else, and the language that pay for the hard stuff are the ones that are complex, because they need to work well with any sort of algorithms.

Strings in D are pretty nice, along with the extremely expressive range algorithms.

Unicode is a slight pain (it's explicitly supported and works fine but it was designed before UTF8 dominated so there's baggage)

Ranges are an absolute pleasure to use, and besides the great template system, my favorite part of D

Reply on news.ycombinator.com