Хмм, а треугольник вы тоже наследуете от трапеции? Ведь трапеция с нулевой длиной основы — тоже треугольник. Это ведь разные фигуры. Зачем здесь наследование?
На счет Generic, то все бы хотели этого. Но, как говорит Никита Попов, внедри они Generics, код станет намного медленней работать, даже если он не использует этот функционал. Не знаю что там у них в исходном коде твориться, но это очень странно.
Перегрузка операторов не нужна, так как вызывает WTF при чтении кода. Абсолютно неочевидно, что та или иная операция на самом деле будет вызывать какой-то магический метод.
Я добавил пример, посмотрите его пожалуйста.
Пример с иммутабельными переменными выглядит неудачно
Изменил пример. Надеюсь теперь более понятно что я хотел донести.
Union-типы — ужасная ошибка
Сильное заявление. Отчасти я согласен с вами. Как говорят разработчики пыхи, эту вещь они сделали не для написания нового кода, а для хоть какой-то типизации старого, где могут быть переданы разные типы параметров. Но это не решение первичной проблемы — отсутствия перегрузки методов. Люди бы не писали непонятный хлам в параметрах, если была бы перегрузка методов.
С другой стороны, в будущем будет сделать что-то вроде SomeInterface1&SomeInterface2 (параметр должен реализовать перечисленные интерфейсы). Это хорошо, когда мы следуем принципу ISP. Тогда у нас появляется много интерфейсов, и мы могли бы явно указать в параметре что должен уметь делать объект.
Синтаксис атрибутов громоздкий и неудачный в сравнении с @attribute.
Очень странно, я запустил ваш исходник у себя (что я изменил — так это то, что уменьшил в 10 раз количество элементов, так как при 106 ну ооочень долго выполняется), и результаты у нас кардинально отличаются. Можете посмотреть скрин ниже. Запускал из-под 19 студии.
На самом деле очень странно наблюдать такое поведение.
Ещё такой момент. В том же тимсорте есть режим так называемого «галопа», который ускоряет слияние массивов. В моей реализации сортировки я не стал внедрять его. Но это дало бы доп. прирост к скорости.
Это всё конечно очень круто, но в приведённом вами коде сортируются разные массивы. Если мы рандомно сгенерировали массив для сортировки с помощью qsort, а потом генерируем совсем другой массив с другими элементами для алгоритма timsort, то как-то необъективно получается.
1) Когда я начинал писать этот алгоритм, то не планировал его вообще куда-то выкладывать. Я писал так, как мне было удобно работать в тот момент.
2) Опять же мне приятней писать i & 1 чем i % 2 != 0
3) Мы выделяли 2 * len памяти, соответственно освобождаем тоже 2 * len
4) Это решается простой обёрткой над представленной реализацией. Мы же можем полностью скопировать массив и сортировать копию. Предоставленная здесь функция рекурсивная, и в ней есть хитрые манипуляции с памятью.
5) Без обёртки O (3n). Если написать над ней обёртку, то O (4n).
И все же, что вы думаете по этому поводу?
Да, там была опечатка. Я имел в виду статический метод:
Уже поправил.
Хмм, а треугольник вы тоже наследуете от трапеции? Ведь трапеция с нулевой длиной основы — тоже треугольник. Это ведь разные фигуры. Зачем здесь наследование?
Неочевидностей? Каких именно?
На счет Generic, то все бы хотели этого. Но, как говорит Никита Попов, внедри они Generics, код станет намного медленней работать, даже если он не использует этот функционал. Не знаю что там у них в исходном коде твориться, но это очень странно.
Я добавил пример, посмотрите его пожалуйста.
Изменил пример. Надеюсь теперь более понятно что я хотел донести.
Сильное заявление. Отчасти я согласен с вами. Как говорят разработчики пыхи, эту вещь они сделали не для написания нового кода, а для хоть какой-то типизации старого, где могут быть переданы разные типы параметров. Но это не решение первичной проблемы — отсутствия перегрузки методов. Люди бы не писали непонятный хлам в параметрах, если была бы перегрузка методов.
С другой стороны, в будущем будет сделать что-то вроде
SomeInterface1&SomeInterface2(параметр должен реализовать перечисленные интерфейсы). Это хорошо, когда мы следуем принципу ISP. Тогда у нас появляется много интерфейсов, и мы могли бы явно указать в параметре что должен уметь делать объект.Да, мне тоже больше по душе джавовский синтаксис.
На самом деле очень странно наблюдать такое поведение.
2) Опять же мне приятней писать i & 1 чем i % 2 != 0
3) Мы выделяли 2 * len памяти, соответственно освобождаем тоже 2 * len
4) Это решается простой обёрткой над представленной реализацией. Мы же можем полностью скопировать массив и сортировать копию. Предоставленная здесь функция рекурсивная, и в ней есть хитрые манипуляции с памятью.
5) Без обёртки O (3n). Если написать над ней обёртку, то O (4n).
(б) с тимсортом не сравнивал