Эх! А я только заметил… Вы пишите, что "sort все равно копирует перед сортировкой данные в массив, а потом возвращает обратно". Действительно, документация Java именно об этом и говорит. Но зачем, зачем копировать в массив список, чтобы применить сортировку слиянием(!)? Ведь именно этот тип сортировки был разработан для структур данных, имеющих именно последовательный доступ.
То ли я очень устал после рабочего дня, однако javadoc гласит: «This avoids the n*n log(n) performance that would result from attempting to sort a linked list in place.»
Всегда думал, что сложность сортировки слиянием на месте(in place) n log(n), при этом затраты на дополнительную память (если использовать стек) всего лишь log(n), что меньше, замечу, чем АЖ n (при копировании целого списка в массив).
Откуда же они взяли квадратично-логарифмическую сложность? Исходники не проверял, но в документации так и написано, начиная с версии 1.4.2 и вплоть до 1.7.
Как так могло получиться, что максимальный рейтинг постов с количеством минусов 1-5 последовательно растёт, затем следует падение, и потом от 6 до 10 опять равномерный рост?
Насколько я понимаю, интерфейс — ничто иное, как протокол взаимодействия, некоторый набор свойств. А вот абстрактный класс — это тот же протокол, но нагруженный частичной реализацией.
И интерфейсы, и абстрактные классы позволяют работать с деревом потомков как с единым типом. Не это ли суть ООП?
Как советуют сильные мира сего, следует использовать интерфейсы везде, где только возможно, а абстрактные классы — только в случае крайней необходимости (ну, например, при реализации паттерна проектирования Template Method). Хотя это весьма спорный момент, но время идёт, а базовые концепции ООП пересматриваются.
В C++ интерфейсов нет, хотя они и достаточно просто реализуются средствами языка. Но так как их нет, они и не используются особо. Java же вынуждает реализовывать интерфесы в тех случаях, когда необходим аналог «множественного наследования».
Никто не мешает спроектировать язык так, чтобы можно было делать и так, и эдак. Хочешь — форматируй скобками, хочешь — и отступами, и скобками, хочешь — только скобками. Haskell — тому пример. Этот язык эту проблему решил интересным образом: просто на некотором этапе обработки исходного кода транслятор вставляет фигурные скобки и точки с запятыми в нужных местах (в зависимости от отступов), если это не сделал программист.
Как по мне, лучше предоставить гибкость, чем насаждать.
В Haskell'е можно оформлять только отступами без скобок (как в Python), можно оформлять только скобками без отступов и оформлять отступами со скобками (как в C, Java и т.п.). Кому как больше нравится.
В данном случае в одном выражении одна и та же переменная изменяется несколько раз. Стандарт говорит нам, что в таком случае поведение неопределено. Подробнее см. «точки следования». Иногда на собеседованиях специально задают подобные задачи, чтобы узнать, разбирается ли кандидат в вопросе, открывал ли стандарт. Как еще один пример неопределенного поведения: i = ++i + ++i;
И как переполнение влияет на результат? Именно на переполнении и основан такой эффект обмена переменными. Или в СИ возможна манипуляция флагом переполнения напрямую? Тогда было бы замечательно при выполнении сдвига влево принимать решения на основании этого флага, к примеру.
Говорят, что славяне произошли от индийских брахманов, о чём свидетельствует гаплогруппа R1a (легко запомнить как Р-один-а -> Родина).
Хотя существует и противоположная точка зрения, что славяне пришли в индию и принесли туда санскрит.
То ли я очень устал после рабочего дня, однако javadoc гласит: «This avoids the n*n log(n) performance that would result from attempting to sort a linked list in place.»
Всегда думал, что сложность сортировки слиянием на месте(in place) n log(n), при этом затраты на дополнительную память (если использовать стек) всего лишь log(n), что меньше, замечу, чем АЖ n (при копировании целого списка в массив).
Откуда же они взяли квадратично-логарифмическую сложность? Исходники не проверял, но в документации так и написано, начиная с версии 1.4.2 и вплоть до 1.7.
А, часом, не Закон Бенфорда виноват ли?
И интерфейсы, и абстрактные классы позволяют работать с деревом потомков как с единым типом. Не это ли суть ООП?
Как советуют сильные мира сего, следует использовать интерфейсы везде, где только возможно, а абстрактные классы — только в случае крайней необходимости (ну, например, при реализации паттерна проектирования Template Method). Хотя это весьма спорный момент, но время идёт, а базовые концепции ООП пересматриваются.
В C++ интерфейсов нет, хотя они и достаточно просто реализуются средствами языка. Но так как их нет, они и не используются особо. Java же вынуждает реализовывать интерфесы в тех случаях, когда необходим аналог «множественного наследования».
Например Map.Entry.
Так вот. Код с отступами:
Код, который генерирует транслятор:
Как по мне, лучше предоставить гибкость, чем насаждать.
Хотя существует и противоположная точка зрения, что славяне пришли в индию и принесли туда санскрит.