Hacker News Reader

Comment by bluetomcat | Hacker News Reader

Another nice feature of C strings is that a substring spanning to the end is essentially p + something. You can also insert temporary null-chars in the middle and have copy-free substrings.

Most other high-level languages would let you copy the substring even if you don't intend to modify it.

View on HN

> Most other high-level languages would let you copy the substring even if you don't intend to modify it.

C++, std::string yes. But for example Java, C# and Go (slices) substring doesn't copy data.

Didn't java change its behaviour?

Yes: https://news.ycombinator.com/item?id=9862556

That's a bit scary. Some of older Java code relies a bit too much on substring not copying. I think most devs understood it pins the original String char[] buffer until all references are gone.

That was always a JVM specific behavior.

Like C, any dev that makes language assumptions based on the installed compiler, is bound to get burned.

Really? Does java offer no cost guarantees for library functions? If a given method might be O(1) or O(n) at the whim of the JVM, programmers are doomed to failure.

Everything not mentioned here is implementation specific:

https://docs.oracle.com/javase/specs/

Even worse, with partial evaluation or escape analysis it might still be non allocating to use a substring call today.

So the thing about advanced compilers in the java world is that they use defined behaviour(results) to do optimisations. And the best optimisations are about not doing work you can avoid. i.e. if you can avoid doing an allocation at all because the (sub)string you just created is only used locally, the object might not be allocated at all (heap|stack) but just registers are reassigned with temporary values needed to calculate the function. So its already common to have O(n) semantics turn into O(1) or even better O(0) ;).

In the java world results are specced, not how you need to get them. (Exceptions to this rule exist).

The implementation being completely rewritten is fine. Nobody should rely on internal fields or details of function calls.

The implementation changing to be asymptotically worse is not fine.

Also they could have changed the garbage collector to make both cases perform well.

Edit: And the comments you linked have a good point made in them, if you don't assume some bounds on how long a function is going to take, you can't call it ever. substr is not a function that's supposed to be forbidden.

Asymptotics aren't a practical bound on anything - a function documented as being O(1) could still take ten thousand years. In practice outside of hard realtime systems all functions are best-effort and we confirm acceptable performance empirically rather than having any explicit guarantees. I do think a language that made it explicit exactly how long any given function would take would be a good thing, but that would be a much bigger undertaking than Rust's borrow checker.

For java it depends, it seems these days that not copying is a bigger performance issue than copying. So the recent openjdk builds have substring do a copy of the underlying char array. Which can change again. Other JVMs of course are free to do other things again, or mix and match depending on the circumstances.

edit: I believe String is overused in java land and we should have more CharSequence implementations. https://docs.oracle.com/javase/8/docs/api/java/lang/CharSequ...

And rust's substrings ("string slices") don't copy either. The borrow checker adds safe liveness checking too.

std::string::substr does return a copy, but a more idiomatic way to handle sub-strings is to use iterator pairs which of course don't require a copy.

> But for example Java, C# and Go (slices) substring doesn't copy data.

If you're stating that C# Substring doesn't copy the string, that is incorrect; .NET always makes a copy: http://stackoverflow.com/questions/6742923/if-strings-are-im...

Reply on news.ycombinator.com