101 / 42 / 9
Регистрация: 09.12.2012
Сообщений: 596
|
||||||
1 | ||||||
HashSet таки добавляет дубликаты18.04.2015, 13:31. Показов 3582. Ответов 30
Метки нет (Все метки)
Если хранить в нем обычные переменные типа стринг или инт, то без проблем. А вот если добавлять туда объекты пользовательского класса, то ни тут то было((
0
|
18.04.2015, 13:31 | |
Ответы с готовыми решениями:
30
Не работает HashSet: добавляются дубликаты Нужно написать программу, которая выводит дубликаты файлов. Дубликаты ищутся по хеш-сумме файла. Код на С# Дубликаты в HashSet Обсуждение HashSet, в частности- хранит HashSet объекты отсортированными или нет? |
17685 / 12871 / 3365
Регистрация: 17.09.2011
Сообщений: 21,136
|
||||||
19.04.2015, 22:14 | 21 | |||||
Насколько я понял, надо чтобы проверка проходила по содержимому.
А она по факту не проходит. Вместо проверки получается утечка памяти. О, динамики пошли! И сразу же появляется сценарий (довольно распространенный), при котором все вообще полетит к чертовой бабушке:
Потом поговорим о генериках. После них — о СОМ-интеропе. А потом можно и генерацию хэш-кода разобрать. Мораль тут в том, что не стоит пытаться реализовать универсальный метод сравнения двух объектов на идентичность. Просто потому, что в приципе не существует универсального метода их сравнивать: в зависимости от модели сравнение может производиться по-разному, не все поля могут в нем участвовать, идентичность объектов может определяться не просто идентичностью полей и т.д. Хороший пример — DateTimeOffset: 12:00 по Гринвичу и 16:00 по Москве — один и тот же момент времени, хотя значение времени (12:00/16:00) и значение часового пояса (+0/+4) у них различны. Про производительность сравнения и генерации хэш-кода (особенно хэш-кода!) с использованием рефлексии и динамиков можно даже не говорить.
5
|
101 / 42 / 9
Регистрация: 09.12.2012
Сообщений: 596
|
|
20.04.2015, 09:15 [ТС] | 23 |
Да он просто пример не тот привел, но понятно в чем дело. Исправил и запушил
Тут спорить не буду, но у меня не столь большие коллекции чтобы это было критично. Пример отличный, но не уместный в данном контексте задачи. Добавлено через 1 минуту ps если еще косяки найдете по факту то пишите, буду рад
0
|
20.04.2015, 09:28 | 24 |
Так вы еще от самого первого не избавились. Повторяю еще раз.
1. Необходимость наследования от вашего класса отсекает возможность наследования от еще одного класса (в C# множественное наследование реализации не поддерживается, и обойти это не получится). 2. Исходя из п.1, сразу возникает необходимость прикреплять к проекту еще и файл с вашим классом, что тоже не радует. 3. И как правильно указал ув. kolorotur, не всегда сравнение необходимо производить по всем свойствам объекта. Вполне возможен вариант, что для сравнения на идентичность необходимо выбрать не все поля/свойства, а лишь некоторые, на усмотрение разработчика. Т.о., придется мало того что наследоваться от вашего класса, так еще и исправлять его, что сводит на нет всю его универсальность. Так что, на мой взгляд, идея не имеет смысла. Гораздо проще переопределить два/три метода в своем классе, если это необходимо.
0
|
17685 / 12871 / 3365
Регистрация: 17.09.2011
Сообщений: 21,136
|
|
20.04.2015, 11:14 | 25 |
Исключение вылетает. Вы последнюю версию пробовали, ту, что с динамиками?
Вот тут становится не понятно: если вы пишете решение под данный контекст задачи, то чем вас не устроило быстрое, простое и эффективное решение, предложенное в самом начале темы? А если вы пишете универсальный метод сравнения, то причем здесь данный контекст задачи? Вот уже для простого, казалось бы, сравнения двух объектов к динамикам добавилась XML-сериализация. Это значит, что решение будет падать на свойствах, которые выбранный метод сериализации не поддерживает. Я вам приведу пример, вы его исправите, внедрив еще какой-нибудь костыль. Я вам покажу пример краша под этот костыль. Вы добавите еще один костыль для костыля. И так до бесконечности. Точнее до того момента, когда у вас не останется инструментов, после чего я напишу объект, сравнение на равенство которого не поддерживается ни одним из используемых вами инструментов. Для любого "универсального" решения я вам приведу пример, при котором это решение не работает — просто потому, что у любого инструмента есть ограничения по его применению. По факту же, пытаясь добавить гибкость, вы убиваете в ноль производительность, при этом гибкости не добавляя.
1
|
Master of Orion
|
||||||
20.04.2015, 15:27 | 29 | |||||
beats, темы тут не закрывают
kolorotur, я на этом примере вызывал:
0
|
17685 / 12871 / 3365
Регистрация: 17.09.2011
Сообщений: 21,136
|
|
20.04.2015, 15:46 | 30 |
Psilon, на битбаките была версия, где значения свойств двух объектов выгружались в динамики и потом сравнивались через оператор !=.
Поймите правильно — я не придираюсь к вашей реализации, а пытаюсь провести в обход поля, выстланного граблями и объяснить почему по нему не стоит идти напрямую. До вас не одно поколение программистов себе на нем шишки набило — зачем повторять чужие ошибки?
0
|
Master of Orion
|
||||||
20.04.2015, 16:25 | 31 | |||||
kolorotur, а не, не глядя написал. Там была версия с двумя динамиками, да, просто я её не сохранил, а потом студия грохнулась и история изменений вместе с ней, а репозиторий уже удален.
Но возражение с моей ТЗ: насколько это медленно. В принципе у меня была идея сделать универсальный класс, который мог бы генерировать GetHashCode() для любых типов. То есть этакий
Добавлено через 2 минуты Хотя в принципе от EqualityComparer<T> отличаться будет разве что скоростью.
0
|
20.04.2015, 16:25 | |
20.04.2015, 16:25 | |
Помогаю со студенческими работами здесь
31
HashSet. Удалить объект-класс из HashSet Contains for HashSet HashSet HashSet Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |