4 ms·
How would you fix this? Possibly by copying the input array to a local array as the first step? But then you might copy a lot of data, which is in 99% of the ca
by haspok 3y ago
How would you fix this? Possibly by copying the input array to a local array as the first step?
But then you might copy a lot of data, which is in 99% of the cases totally unnecessary.
Have a separate threadsafe and a non-threadsafe constructor for char[]?
EDIT: another idea is to do a hash of the input array, and compare between start and end. But that also requires an O(n) walk through the input...
- silon42 3y ago/s redesign a language to prevent parallel mutable use of the array
- pshirshov 3y agoThis won't happen (unfortunately) for obvious reasons.
- tpxl 3y ago> But that also requires an O(n) walk through the input... Compressing requires an O(n) walk through the input either way.
- orra 3y agoYes. In fact, both String.valueOf(char[]) and constructor String(char[]) are already documented as copying the array contents.
- the_mitsuhiko 3y agoI'm not sure how much of the underlying implementation details of arrays are leaking into JNI, but one way to approach it would be with first class copy-on-write for arrays or opt-in immutability (freezing).
- barrkel 3y agoCopy the array, then use alias analysis to remove the copy most of the time, by having two versions of the String constructor, with a version chosen based on aliasing.
- masklinn 3y ago> How would you fix this? Possibly by copying the input array to a local array as the first step? Upon encountering a non-Latin1 char, convert the existing latin1 array to an utf16 one, append the char (converted), then resume iteration in utf16 copy mode. This way you know the char which made you bail out on Latin1 is part of the output.