Jawa / Говнокод #8431 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
@Override public int hashCode()
    {
        int hash = 7;
        return hash;
    }

Ну это явно хит!

Запостил: dwinner dwinner, (Updated )

Комментарии (46) RSS

    • Не, немного не то, но близко.
      А прикинь, случайное число в качестве хэша?
      Ответить
    • сначала пиши, потом подписывайся. не наоборот.
      fix: O(1)
      Ответить
    • Год - гавно говоришь?! Вот уж никогда бы не подумал... Ну а сайт-то как называется?! 🙂
      Ответить
    • То, что сортировка и поиск в коллекциях для данных объектов отработает неправильно - очевидность!
      А, ну точно. Надо ж похвалиться, что вы типа знаете, как-то сразу не подумал... Sorry
      Ответить
      • >То, что сортировка и поиск в коллекциях для данных объектов отработает неправильно - очевидность!
        Сортировка отработает правильно, поиск - тоже. Медленно, правда, искать будет.

        >очевидность!
        Как видно, для тебя это оказалось не очевидным.
        Ответить
        • Следуя вашей логике: медленно и правильно это синонимы?
          Ответить
          • ошибки в реализации алгоритма нет. реализация алгоритма будет выдавать верные результаты работы, пусть и с намного более низкой скоростью
            Ответить
            • Согласен. Не те слова использовал... Тем не менее хэш-конфликты при каждой попытке упорядочивания HashMap'ов, TreeMap'ов... есть ошибка, хоть JVM об этом ничего "не говорит". Утечка памяти - менее очевидная проблема... Про недостижимые участки памяти в куче JVM тоже молчит, а GC ничем помочь не может, и всё же это ошибка, допущенная (с высокой степенью вероятности) разработчиком. Может быть я не совсем точно подобрал для этого всего слово "Ошибка"...
              Ответить
                • Чтоб элемент в хэш-таблицу вставить вычисляется хэш-код, потом делится на общее кол-во ячеек. Полученное число - номер ячейки. Если такой номер есть, возникает хэш-конфликт. Вставка, сортировка - это же модификация?! В чем же херня?
                  Ответить
                  • Сортировка хэш-таблицы - конечно, херня. А конфликты - дело обычное, они возникают при любом определении хэш-кода.
                    А когда вы начали вещать о мемори-ликах, JVM и GC у меня сложилось вмечатление, что вы просто перечисляете знакомые слова.
                    Ответить
                    • Сортировка хэш-таблицы - херня, согласен, лучше списки использовать, ОКЭ!
                      Ответить
                    • >Сортировка хэш-таблицы - конечно, херня
                      А между тем, есть контейнеры, правда в стандартных библиотеках я их ни разу не видел, снижающие максимальную сложность поиска в хештаблице О(n/k) до О(log(n/k)) (k=размер хештаблицы=const) при условии правильно подобранной хешфункции или О(n) до О(log(n)) при неправильно подобранной хешфункции. А именно за счет сортировки колизиирующих элементов в одном элементе хештаблицы. То есть для таких контейнеров, даже если написать такую хешфункцию, как написал автор этого говнокода, то он все равно получает поиск О(log(n)), а не О(n).
                      Ответить
                      • Для этого, наверное, списки нужно заменить деревьями и требовать наличия строгого отношения порядка для хранимых элементов
                        Ответить
                        • Мне кажется, это будет медленнее из-за константы.
                          Ответить
                          • Да, лучше уж таблицу побольше сделать и функцию хэширования хорошую подобрать
                            Ответить
                            • >Да, лучше уж таблицу побольше сделать
                              Кстати, не видел я что-то в C# для Dictionary параметра размера хештаблицы k. Он там регулируется как-нибудь?
                              Ответить
                              • не знаю, как в C#, а в Java в конструкторе HashMap есть параметр loadFactor, при достижении которого у HashMap'ы случится resize
                                Ответить
                          • >Мне кажется, это будет медленнее из-за константы.
                            Можно поподробнее?
                            Ответить
                            • Что подробнее? Если k достаточно большое, то разница между n/k и log(n/k) окажется слишком мала, чтобы перекрыть проигрыш от возни с деревом.
                              Ответить
                              • Ну, это само собой, в таких случаях этот контейнер и не используют. Используют тогда, когда хешфункцию правильно подобрать тяжело.
                                Ответить
                          • В HashMap по умолчанию loadFactor равен 0.75. В любом случае говорить о O(n/k) и O(log(n/k)) нет смысла.
                            Ответить
                            • есть смысл, если поставить лоадФактор овер 9000
                              а вообще, я говорил не про стандартную библиотеку java, если ты не заметил
                              Ответить
                • public class Stack
                  {
                  private Object[] elements;
                  private int size = 0;
                  private static final int DEFAULT_INITIAL_CAPACITY = 16;

                  public Stack()
                  {
                  elements = new Object[DEFAULT_INITIAL_CAPACITY];
                  }

                  public void push(Object e)
                  {
                  ensureCapacity();
                  elements[size++] = e;
                  }

                  public Object pop()
                  {
                  if (size == 0)
                  throw new EmptyStackException();
                  return elements[--size];
                  }

                  private void ensureCapacity()
                  {
                  if (elements.length == size)
                  elements = Arrays.copyOf(elements, 2 * size + 1);
                  }
                  }

                  Код компилится, но память течет... Тоже что ли херня?! Мож я просто не понимаю значения слова херня?! )))
                  Ответить
                    • Слова конечно знакомые... Но я ж про ошибки веду дилемму, про концептуальные ошибки, кстати слово "концептуальные" тоже где-то слышал, какое совпадение...
                      Ответить
      • Сортировка и hash-код вещи в каком-то смысле противоположные. Такое определение hash-код ничего не сломает, разве что поиск элементов будет медленным (как уже сказал XXXGovno), поскольку хэш-код будет давать плохое распределение экземпляров. Правильная сортировка же достигается имплементацией Comparable или определением Comparator'а.
        ваш К.О.
        Ответить
    • Нет, хотя было бы забавно. Это сгенерил NetBeans, я в спешке поля не указал, не сразу заметил...
      Ответить
  • // The worst possible legal hash function - never use! (c) Effective JavaTM Second Edition
    Ответить

Добавить комментарий

Помни, guest, за тобой могут следить!

    А не использовать ли нам bbcode?


    8