4 ms·

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 a

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.

vardump 11y ago
> 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.
- joosters 11y ago
  Didn't java change its behaviour?
  - anon1385 11y ago
    Yes: https://news.ycombinator.com/item?id=9862556 https://news.ycombinator.com/item?id=9862556
    - vardump 11y ago
      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.
      - pjmlp 11y ago
        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.
        joosters 11y ago
        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.
        pjmlp 11y ago
        Everything not mentioned here is implementation specific: https://docs.oracle.com/javase/specs/ https://docs.oracle.com/javase/specs/
        jerven 11y ago
        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).
        Dylan16807 11y ago
        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.
        lmm 11y ago
        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.
- jerven 11y ago
  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/CharSequence.html https://docs.oracle.com/javase/8/docs/api/java/lang/CharSequ...
- kzrdude 11y ago
  And rust's substrings ("string slices") don't copy either. The borrow checker adds safe liveness checking too.
- gpderetta 11y ago
  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.
- zastrowm 11y ago
  > 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-immutable-in-net-then-why-does-substring-take-on-time http://stackoverflow.com/questions/6742923/if-strings-are-im...

vardump 11y ago

> 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.

joosters 11y ago
Didn't java change its behaviour?
- anon1385 11y ago
  Yes: https://news.ycombinator.com/item?id=9862556 https://news.ycombinator.com/item?id=9862556
  - vardump 11y ago
    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.
    - pjmlp 11y ago
      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.
      - joosters 11y ago
        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.
        pjmlp 11y ago
        Everything not mentioned here is implementation specific: https://docs.oracle.com/javase/specs/ https://docs.oracle.com/javase/specs/
        jerven 11y ago
        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).
      - Dylan16807 11y ago
        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.
        lmm 11y ago
        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.
jerven 11y ago
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/CharSequence.html https://docs.oracle.com/javase/8/docs/api/java/lang/CharSequ...
kzrdude 11y ago
And rust's substrings ("string slices") don't copy either. The borrow checker adds safe liveness checking too.
gpderetta 11y ago
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.
zastrowm 11y ago
> 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-immutable-in-net-then-why-does-substring-take-on-time http://stackoverflow.com/questions/6742923/if-strings-are-im...