I
Плюс F# нет в JVM мире, там темно и грустно
Size: a a a
2021 January 13
AT
Почему не RBB-Trees, например?
А в чем проблема самому соорудить?
g
А в чем проблема самому соорудить?
Это ко мне вопрос? :)
AT
Это ко мне вопрос? :)
Вряд ли :)
AT
Ну стандартная библиотека действительно сглаживает эти различия. То есть ты постоянно при работе с модулем Array получаешь новые массивы
Эм. А как иначе то, без создания нового массива ?
I
Бомбой было бы, термоядерной, добавление struct в JVM и кложу, чтобы иметь детерменированную аллокацию в стеке либо плотным массивом в куче, а не когда припрет JIT компилеру либо толпой ссылкок в массиве в куче. Ох сколько можно было бы и на Java шустрого налабать, с предварительной аллокацией, да кешфрендли.
В 16/17 будет превью inline types (но тема для др чата)
I
Эм. А как иначе то, без создания нового массива ?
Sort, filter вполне могут работать без создания нового массива
I
К примеру
AT
Sort, filter вполне могут работать без создания нового массива
Не, я про модификацию
AT
Хотя sort
I
Sort, filter вполне могут работать без создания нового массива
Вопрос, конечно, что должен возвращать filter в таком случае
AT
Странно, профита тогда нет. С аллокацией нового массива я всегда уверен, что не надо блокироваться для консистентности в случае-если один поток добавляет новый/элемент в массив либо удаляет, а другой к примеру просто итерирует
g
Sort, filter вполне могут работать без создания нового массива
Array.sortInPlaceI
Кстати, если уж говорить ещё о новых скобочках, то я придумал для stackalloc: [! !]
I
или даже [!!! !!!], хаха
PD
Array.sortInPlaceЖаль, что in-place версия есть только и только для сортировки
g
Жаль, что in-place версия есть только и только для сортировки
А что еще нужно?
PD
Ну например map, тоже не меняет размер массива