Возьмём изображения строчных букв u и v, с идущим по умолчанию в IDEA размером 13.
Совместим изображения букв по верхней и левой кромкам. Пиксели, занимаемые буквой u обозначим красным цветом, занимаемые буквой v — зелёным, а совпадающие в начертаниях обеих букв — серым. Для удобства увеличим изображение:
Вы по-прежнему считаете их форму «совершенно разной»?
Большинство «hack it!» довольно однотипны. Декомпилировал — получил ответ.
В Android-разработке действительно так востребованы навыки реверс-инжиниринга?
Приползло с новым EAP идеи.
Цифры понравились, напомнили шрифты старых матричных принтеров, печатавших ещё на рулонах с перфорацией по бокам. Цифра 3 с горизонтальной верхней линией тоже плюс к читаемости.
Но вот буквы…
Предлагаете отличать u от v по тому, насколько острый кончик у строчной буквы?
Вернул старый шрифт.
Пока ты студент, не умеющий программировать — замечательная вещь. Как только начинаются серьёзные проекты и основная работа с GUI принимает форму доработки собственных визуальных компонентов, «визуальность» уже не воспринимаешь как что-то значимое. Зачастую проще и удобнее сформировать UI в коде.
объектную модель, статическую сильную типизацию
Языков с ООП вагон и маленькая тележка, как и с сильной типизацией. Никаких выдающихся достижений тут у Delphi нет.
В текущей реализации всё отдано на откуп компилятору.
В каком порядке он геттеры в статические параметры invokedynamic загонит, в таком и будут проверяться:
/**
* Generates a method handle for the {@code equals} method for a given data class
* @param receiverClass the data class
* @param getters the list of getters
* @return the method handle
*/
private static MethodHandle makeEquals(Class<?> receiverClass,
List<MethodHandle> getters) {
...
for (MethodHandle getter : getters) {
MethodHandle equalator =
equalator(getter.type().returnType()); // (TT)Z
MethodHandle thisFieldEqual =
MethodHandles.filterArguments(equalator, 0, getter, getter); // (RR)Z
accumulator =
MethodHandles.guardWithTest(
thisFieldEqual, accumulator, instanceFalse.asType(rr)
);
}
return MethodHandles.guardWithTest(
isSameObject,
instanceTrue,
MethodHandles.guardWithTest(isInstance, accumulator.asType(ro), instanceFalse)
);
}
Скорее всего проверки пойдут в порядке декларации полей.
Программист захочет — сам поля в записи переупорядочит.
На уровне javac со времён Java 7 в компиляции перечислений ничего не изменилось, javac из OpenJDK 14 по-прежнему поддерживает не больше
2_746 элементов в перечислении.
Тем интереснее искать теоретически достижимый максимум.
В уме посчитать обычно проще и быстрее, чем эмпирические опыты проводить.
Проверка на работоспособность, безусловно, будет. Неработающий код нам не нужен.
Один switch со всеми элементами?
Так-то можно обрабатывать фрагментами, помещая в ветку default вызов метода с обработкой следующего фрагмента.
С ходу можно прикинуть:
Пропусков у ordinal() нет, заголовок у tableswitch занимает ~16 байтов, дальше — по 4 байта на каждый вариант. Плюс, как минимум, aload_<n> и invokevirtual OurEnum::ordinal() в начале и return в конце.
(65_535 - 16 - 1 - 1 - 3) / 4 ~ 16_378 элементов, дальше будет Code too large.
Интрига в том, сможем ли мы дойти до этого числа.
А редактор кода в RAD Studio, если говорить о среде, не хуже, если наоборот не мощнее чем, например в VS (я работал в обоих).
Непосредственно редактор — лишь малая часть современной IDE. Что там с фоновым анализом кода на ошибки, рефакторингом, быстрыми исправлениями в современной RAD Studio?
Сможет потягаться на равных с IntelliJ IDEA?
Возьмём изображения строчных букв
uиv, с идущим по умолчанию в IDEA размером 13.Совместим изображения букв по верхней и левой кромкам. Пиксели, занимаемые буквой
uобозначим красным цветом, занимаемые буквойv— зелёным, а совпадающие в начертаниях обеих букв — серым. Для удобства увеличим изображение:Вы по-прежнему считаете их форму «совершенно разной»?
Большинство «hack it!» довольно однотипны. Декомпилировал — получил ответ.
В Android-разработке действительно так востребованы навыки реверс-инжиниринга?
В одном чате хорошо работала фраза «Всем удачи!»
Мудаки, проникшие во все области человеческой деятельности — вот действительно серьёзная проблема современного общества.
P.S. Перед написанием комментария я проверил, слово «мудак» не является словом из пяти тире: https://ru.wikinews.org/wiki/Роскомнадзор_разрешил_мудаков
Эволюция участника конференции:
Участвует в конференции ⇒ Делает доклады на конференции ⇒ Выступает с открывающим или закрывающим докладом ⇒ Отказывается от участия в конференции.
Если уж переходить, то на Java, C# или пусть даже на PHP.
Строгой типизации нет, ООП нет, даже банального оператора
caseи того нет. Ну да, «почти».fire4 красиво пылает.
Приползло с новым EAP идеи.
Цифры понравились, напомнили шрифты старых матричных принтеров, печатавших ещё на рулонах с перфорацией по бокам. Цифра
3с горизонтальной верхней линией тоже плюс к читаемости.Но вот буквы…
Предлагаете отличать
uотvпо тому, насколько острый кончик у строчной буквы?Вернул старый шрифт.
12 часов на работе и подъём минимум в 6 00? Нафиг так жить?
Это что-то на эльфийском, возможно — проклятие.
Пока ты студент, не умеющий программировать — замечательная вещь. Как только начинаются серьёзные проекты и основная работа с GUI принимает форму доработки собственных визуальных компонентов, «визуальность» уже не воспринимаешь как что-то значимое. Зачастую проще и удобнее сформировать UI в коде.
Языков с ООП вагон и маленькая тележка, как и с сильной типизацией. Никаких выдающихся достижений тут у Delphi нет.
В текущей реализации всё отдано на откуп компилятору.
В каком порядке он геттеры в статические параметры
invokedynamicзагонит, в таком и будут проверяться:Скорее всего проверки пойдут в порядке декларации полей.
Программист захочет — сам поля в записи переупорядочит.
Вот уж не думал, что качан капусты это хтоническое чудовище.
На уровне javac со времён Java 7 в компиляции перечислений ничего не изменилось, javac из OpenJDK 14 по-прежнему поддерживает не больше
2_746 элементов в перечислении.
Тем интереснее искать теоретически достижимый максимум.
Человек смертен, кто бы мог подумать!
Иии?
Вы не депутат, случайно?
В уме посчитать обычно проще и быстрее, чем эмпирические опыты проводить.
Проверка на работоспособность, безусловно, будет. Неработающий код нам не нужен.
А если попробовать заставить распозновать речь на болгарском так, словно это речь на русском? Насколько неудобоваримая каша на выходе получится?
С точки зрения правописания, понятное дело, никаких шансов. Но вдруг в получившемся наборе букв можно угадать исходное слово?
Один
switchсо всеми элементами?Так-то можно обрабатывать фрагментами, помещая в ветку
defaultвызов метода с обработкой следующего фрагмента.С ходу можно прикинуть:
Пропусков у
ordinal()нет, заголовок уtableswitchзанимает ~16 байтов, дальше — по 4 байта на каждый вариант. Плюс, как минимум,aload_<n>иinvokevirtual OurEnum::ordinal()в начале иreturnв конце.(65_535 - 16 - 1 - 1 - 3) / 4 ~ 16_378элементов, дальше будетCode too large.Интрига в том, сможем ли мы дойти до этого числа.
Непосредственно редактор — лишь малая часть современной IDE. Что там с фоновым анализом кода на ошибки, рефакторингом, быстрыми исправлениями в современной RAD Studio?
Сможет потягаться на равных с IntelliJ IDEA?
Зависимость от количества элементов не совсем линейна, небольшой спойлер из второй части: