Когда нужно «быстро», обычно, о прочих затратах не думают. Какие размеры массива? Гигабайты?
А ещё если не указывают, на каком процессоре должен исполняться код - значит не так уж и важна скорость. Скорее, просто чтоб быстрее обычного перебора было
А какие, собственно, есть еще варианты кроме формирования другого массива, в который элементы добавляются после проверки на отсутствие в нем?
Да, с гигабайтами интереснее)
Ну покажи решение своё, чего тянуть
1 проход: кэширование ключа каждого элемента и при встрече одинакового элемента (с кэшем сравнивать), помечать его на удаление. 2 проход: удаление удалённых элементов, копированием неудалённых. Идея в том, что кэш делать индексированным, для быстроты поиска. Мне кажется это было бы быстрее, чем искать в массиве дубле. Но это моя топорная идея и она очень далека от крутых алгоритмов
Это просто оптимизация исходного варианта с целью экономии памяти. Будет плохо работать если имеем длинный массив с элементами малого размера.
Хорошая функция хэширования, а ещё и если её вызывать очень часто, может покрыть даже работу с памятью. Но всё же зависит от того, какая хэш-функция используется. CRC, вроде, не такой уж и затратный
Но 2 почти одинаковых массива, это тоже дорого (по памяти). Тогда может лучше исходный массив обходить, ища дубли после текущей позиции и при нахождении помечать на удаление?
Дубль может быть в самом начале и в самом конце
Да. И тогда на первом шаге придётся пройтись по всему массиву
Обсуждают сегодня