- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
@Override
public Object clone() {
try {
return super.clone();
} catch (Exception e) {
return this;
}
}
Jawa / Говнокод #7303
0
"Клонирование"
Запостил: 
auf1r2,
(Updated )
ёкарный бабай!
equals и hashCode нет вообще
то есть, так и нужно.
Из этой же серии "проверка на нечетность".
public boolean isOdd(int value) {
return value % 2 == 1;
}
Отсутствие проверки переполнения не оправдано ничем.
есть нормальный Python, но whitespace там имеет значение и синтаксис
есть нормальная Java, но медленная и в песочнице
есть нормальные С\С++, но сложные и остальными низкоуровневыми заморочками
есть нормальный Lisp, но он в деды нам всем годиться
предлагаю собрать всё вместе, доработать и сочинить песенку.
А это значит, что языки, не удовлетворяющие этим требованиям - ацтой.
1. В твоем нормальном языке по умолчанию выключен контроль переполнения. Когда он тебе нужен ты ставишь директивы компилятору. В java: используется int, когда нужен контроль используем BigInteger.
2. В твоем нормальном языке по умолчанию включен контроль переполнения. Когда он не нужен ты ставишь директиву. В java: используется BigInteger, с откатом до int в случае необходимости.
Итог: один хер приходится следить за переполнением. Только ты ставишь директиву компилятора, а жава-кодеры применяют другой тип.
> это значит, что языки, не удовлетворяющие этим требованиям - ацтой
Это уже диагноз =) Ты тут наверное любимчик =)
Да, именно так.
> В java: используется BigInteger
Кем? Видишь ли, в нормальном языке надо делать лишние движения, чтобы отрубить проверки, а в ненормальным - надо делать движения, чтобы включить.
> Только ты ставишь директиву компилятора, а жава-кодеры применяют другой тип.
Поменять директивы легче, чем поменять тип.
Прикольно обсерать языки, которых не знаешь? BigInteger не проверяет на переполнение, он позволяет работать с числами с произвольной точностью, как Integer в Haskell (где для обычных чисел "с переполнением" есть Int). Python и Lisp при возможности переполнения сами обернут целое число в аналогичную обёртку. Директива компилятора же не сделает целочисленный тип шире. Ну, быть может, уронит программу в случае переполнения. Как видишь, разница принципиальна.
Я понял.
> Директива компилятора же не сделает целочисленный тип шире.
Я в курсе. Это твой коллега посоветовал BigInteger в качестве решения. Пойми одну вещь - облажаться из-за того, что ЗАБЫЛ включить проверку/широкий тип итд, намного легче, чем облажаться из-за того, что СОЗНАТЕЛЬНО ОТКЛЮЧИЛ проверку.
Представляется сразу суровый кодер на Ада, который перед релизом втыкает/вырезает в 1.500.000 строках кода директивы компилятора для отключения/включения проверок... Надеюсь, у компилятора и для этого есть опция )
Во-первых, можно отрубить во всём проекте. Можно отрубить в модуле. Можно найти узкое место (одну функцию) и отрубить только в ней.
По умолчанию язык навязывает именно опасный тип, что очень плохо.
что очень быстро.
круто.
а на каждую мало-мальски значимую операцию.
например объявление перменной нужно ввести checked OutOfMemoryException.
Тарас просто любитель переусложненной и тяжеловесной Ады, которая не делает код надеждней, а только усложняет и тормозит его.
Ты меня прям затроллил этой фразой, я аж почувствовал БАТТХЁРТ и заминусовал твой коммент.
Тогда весь твой предыдущий пост - необоснованное гонево.
> К счастью, в Java их нет.
Обоснуй. Твой предыдущий пост - слив, не считается.
> А вы, скорее всего, промышленному программированию отношения не имеете.
Если тебя устраивают баги из-за целочисленного переполнения, то не тебе судить мою компетентность.
> Учите дальше школьников вычислять палиндромы. Не разводите холивары и не мешайте людям глумиться над промышленным говном. Пожалуйста.
Не учи меня, что мне делать. Пожалуйста.Ты слишком глуп для этого, в тебе слишком много агрессии на Паскаль.
КАК Вы собираетесь решить проблему переполнения в методе compareTo() при помощи, предположим, директив? В любой нормальной книжке по java проблема переполнения упоминается (взять, хотя бы, CoreJava), и единственная мера борьбы с ней - использование условных операторов. Проверка на нечётность легко проверяется побитовыми операциями.
>Если тебя устраивают баги из-за целочисленного переполнения, то не тебе судить мою компетентность.
Меня не устраивают любые баги, нужно просто уметь избегать подобных ошибок. Язык тут не при чём, если причина в физике.
> Ты слишком глуп для этого, в тебе слишком много агрессии на Паскаль.
Во мне нет агрессии к паскалю, ибо язык довольно строен и богат, у меня отвращение к его проповедникам, поливающим гавно на мэйнстрим. Кстати, Никлаус Вирт считал Аду, мягко говоря, кровавым выпердышем.
http://img0.liveinternet.ru/images/attach/c/1//45/729/45729569_Trolli.jpg
Ну так и пиши условные операторы!
> Меня не устраивают любые баги, нужно просто уметь избегать подобных ошибок. Язык тут не при чём, если причина в физике.
Язык должен предоставлять средства от подобных ошибок. Если создатели языка не осилили встроить проверку на переполнение, то это большой МИНУС языка, и как ни отмазывайся, это будет МИНУС.
> Во мне нет агрессии к паскалю
> Представляю также, как "быстро" работает код, требующих большого числа вычислений, когда при каждой арифметической операции проверяются регистры OF и CF... Вы, батенька, сразу видно, не практик
Ну да, ну да...
> Кстати, Никлаус Вирт считал Аду, мягко говоря, кровавым выпердышем.
Слово "выпердыш" уже ты вставил. Скажи ещё, "хероподгандонным захуищем", чтобы ещё красочнее было!
Так вот, в 83 году Ада казалась сложной, да, но это был 83 год, С++ в нынешнем виде ещё не было.
И мнение Вирта нельзя считать объективным, так как он тоже участвовал в том конкурсе на военный язык и пролетел.
Таки пишу, товарищ, пишу. А когда реально нужна арифметика без переполнения (допустим, операции с финансами), использую стандартные классы BigInteger и BigDecimal, реализующие операции над числами с произвольной точностью без переполнения.
>Слово "выпердыш" уже ты вставил
А я вроде quote и (c) нигде не ставил.
Дискуссия себя явно исчерпала. Прощайте, сударь.
Нездоровый образ жизни у меня какой-то.
quote=roman-kashitsyn
>есть нормальный Haskell, чтоб на нём писать, нужно сперва напиться
Ох лол. Тут с Тарасом не поспоришь, да.