You can easily run into problems with languages with automatic string handling if you don't know how the language handles things under the covers.
If you have an algorithm that iteratively cuts off and processes the head of a string until the string is consumed, the way to get the tail of the string can affect the performance.
If making a new string containing the tail of the original string just references the original string data, the obvious solution may work fine. If instead it involves a memory allocation and string copy, then the algorithm may exhibit quadratic performance w.r.t. the string length.
And this isn't just a case of one string handling method being better than the other: with the first strategy, taking a 100 character slice of a 100K string might prevent the large string from being released.
For all its faults, at least these sort of trade-offs are usually visible in C string handling.
Posted Jun 30, 2012 17:03 UTC (Sat) by HenrikH (guest, #31152)
[Link]
Exactly, I have encountered numerous people who are baffled when += "some string" all of the sudden gets slow as molasses.
Why learn C? (O'Reilly Radar)
Posted Jul 3, 2012 13:36 UTC (Tue) by alankila (subscriber, #47141)
[Link]
*sigh* I should have predicted that my simple comment would end up in this sort of discussion and worse yet would make me look foolish. ;-)
Let's just say that your point is valid and correct. It still does not make me look C-style "string" handling favorably. The few instances where you have to take a copy to detach a substring from a longer string, or to avoid quadratic performance of string concatenation loops are imho not materially significant compared to the benefits of making strings easy and nice to use.