Илюха, остановись!
Илюха, не останавливайся!
}
}
}
Кто первый оптимизирует код - выдам медальку.
&&
Я отрефакторил:
На каждое условие поставить отрицание, если оно срабатывает - возвращать false.
В самом днище вернуть true.
На каждое условие поставить отрицание, если оно срабатывает - возвращать false.
В самом днище вернуть true.
один раз в локальную переменную скастить obj в user
вово, только за это руки поломать хочца, столько беспощадных кастовок пиздец
Ещё нужно после проверки типа добавить проверку, не является ли наш obj тем самым this, то есть не сравниваем ли мы объект сам с собой, что однозначно и без всяких доп. проверок должно давать true.
Да и там 95% проверок вообще нафиг не нужны для логики работы приложения, можно даже ID сделать уникальный, который и на уровне БД будет контролироваться и гарантировать идентификацию конкретного Юзера внутри самого приложения. А ещё представим, что мы сравниваем две копии Юзера, одна до внесения изменений в понравившееся мне поле User.Fetish, а другая после - и один и тот же по сути Юзер уже не эквивалентен самому себе.
Да и там 95% проверок вообще нафиг не нужны для логики работы приложения, можно даже ID сделать уникальный, который и на уровне БД будет контролироваться и гарантировать идентификацию конкретного Юзера внутри самого приложения. А ещё представим, что мы сравниваем две копии Юзера, одна до внесения изменений в понравившееся мне поле User.Fetish, а другая после - и один и тот же по сути Юзер уже не эквивалентен самому себе.
Мне нравится последняя фича
public override bool Equals(object obj) => obj is User user && user.x == this.x && ...
public override bool Equals(object obj) => obj is User user && user.x == this.x && ...
Работает не ломай. За это никто не заплатит.
А теперь поговорим о том, как у этого дерьма будет с производительностью.
Там сверху написано.
Ну если профилировщик не покажет там лагов, то можно и оставить. А не показать он может если объекты не сравнивает никто.
Иисус, ты себе веб-разработчика ищешь что ли?
return (Object)obj == (Object)this;
Если у объектов будет одно различное не сравниваемое свойство (например время создания объектов), или свойство хранящее ссылку, то твой способ будет сасат
Исходим из того, что это потомки одного класса и условие метод класса.
В данном, конкретном случае я вижу только фиксированный перечень свойств.
Методы для экземпляров будут содержать одни и те же ссылки.
Следовательно. Все будет работать.
В данном, конкретном случае я вижу только фиксированный перечень свойств.
Методы для экземпляров будут содержать одни и те же ссылки.
Следовательно. Все будет работать.
А коммент мы читаем жопой.
Этот "фиксированный перечень свойств" может быть иметь свойства, которые не должны сравниваться (в каждом экземпляре они могут быть разные). И если есть свойства, доступные по значению, то ты будешь сравнивать адреса, а не значения. :/
Этот "фиксированный перечень свойств" может быть иметь свойства, которые не должны сравниваться (в каждом экземпляре они могут быть разные). И если есть свойства, доступные по значению, то ты будешь сравнивать адреса, а не значения. :/
Есть кусок кода. В котором перечислены сравниваемые свойства.
Экземпляры одного класса не могут иметь разных свойств.
Ещё раз повторю, что в данном конкретном куске кода все будет работать через логический оператор. Применительно к (справедливо замеченным ниже поправкам ЯП - Шарп) оператр будет сравнивать объекты приведенные к определенному типу данных.
Экземпляры одного класса не могут иметь разных свойств.
Ещё раз повторю, что в данном конкретном куске кода все будет работать через логический оператор. Применительно к (справедливо замеченным ниже поправкам ЯП - Шарп) оператр будет сравнивать объекты приведенные к определенному типу данных.
Ок. Принимаю все замечания. С телефона не увидел ЯП.
Итого. Даже с учётом моих косяков.
Приводим к одному типу объекта и сравниваем объекты.
Если надо проверить ряд свойств - делаем какой-нибудь toString по перечню свойств нужных для сравнения - простой конкатенацией. Сравниваем.
И т.д. и т.п.
Итого. Даже с учётом моих косяков.
Приводим к одному типу объекта и сравниваем объекты.
Если надо проверить ряд свойств - делаем какой-нибудь toString по перечню свойств нужных для сравнения - простой конкатенацией. Сравниваем.
И т.д. и т.п.
А написать единый метод сравнения этих объектов, который будет быстрее, оптимизированней и проще - совесть не позволяет?
А вот нихуя, в твоём примере будут сравниваться адреса в памяти и всё
Приведи к массиву.
Можешь сериализовать и сравнить строки. И ещё
Стопицот вариантов
Кто ж запрещает.
адреса в памяти в php
Можешь сериализовать и сравнить строки. И ещё
Стопицот вариантов
Кто ж запрещает.
адреса в памяти в php
Перед тобой шарпы. :/
Да пох. Общая парадигма остается
Пусть будут адреса. По адресам находятся объекты.
Физически - области памяти. Примени соответственно методами доступными в конкретном ЯП.
Пусть будут адреса. По адресам находятся объекты.
Физически - области памяти. Примени соответственно методами доступными в конкретном ЯП.
Сериализовать и сравнить строку.
Я не программист, но насколько знаю C# при сравнении типа if ( obj1 == _obj1 && obj2==_obj2 && ... && objN==_objN) , будет сравнивать их последовательно и при первом исключении выдаст false. Это должно быть быстрее, чем сериализация.
Мой вариант ебанут и несерьезен по своей сути. Его могут применять только извращенцы, которым лень писать все if'ы. Так что нет смысла раздувать обсуждение по этой хуйне.
Чем больше ты вникаешь в код, тем больше хочется выйти из команды разработки.
Вот поэтому на галерах рабов всегда приковывают цепями.
А в этих ваших шарпах == это не ссылочное сравнение?
смотря с чем. и есть ли IEqualityComparer у объекта, примитивы норм и так проверяются, а объекты по умолчанию по ссылкам, поэтому нужно компарер задавать, сильно не пинайте. полтора года уже шарпы не трогал.
а вариантов в упрощении 2а, либо через рефлексию перебор параметров по атрибутам, не эффективно но в рот ебать, зато не этот ужас, и добавлять ноывые проверяемые элеметы проще, просто въебать их в класс и усе
либо завести массив типа
static List> conditions = new List>() {
(a, b) => a.FirstName == b.FirstName,
(a, b) => a.LastName == b.LastName
};
lst.All(f => user1, user2);
а вариантов в упрощении 2а, либо через рефлексию перебор параметров по атрибутам, не эффективно но в рот ебать, зато не этот ужас, и добавлять ноывые проверяемые элеметы проще, просто въебать их в класс и усе
либо завести массив типа
static List> conditions = new List>() {
(a, b) => a.FirstName == b.FirstName,
(a, b) => a.LastName == b.LastName
};
lst.All(f => user1, user2);
На кой эти свистелки с лямбдами, чем обычное
return
a.FirstName == b.FirstName &&
a.LastName == b.LastName &&
...
a.Fetish == b.Fetish;
не устроило?
return
a.FirstName == b.FirstName &&
a.LastName == b.LastName &&
...
a.Fetish == b.Fetish;
не устроило?
длинная портянка, и если переделать чутка в compare, то можно с помощью линка Any(f(u,u2) 0) и т.п.
да это менее эффективно чем портянка, но я вообще не понимаю зачем использовать шарп если нужна производительность, единственное чем он мне нравится так это гибкость и быстрота разработки, нужна скорость юзай ++
да это менее эффективно чем портянка, но я вообще не понимаю зачем использовать шарп если нужна производительность, единственное чем он мне нравится так это гибкость и быстрота разработки, нужна скорость юзай ++
над писать
var u = obj as User;
return u != null && (u == this || (u.FirstName == this.FirstName && u.LastName == this.Last name ... ... u.Fetish = this.Fetish));
рефлексия медленная и не даст контроля над списком сравниваемых полей. А вообще Equals переопределять не надо, ни к чему хорошему это не приведёт.
var u = obj as User;
return u != null && (u == this || (u.FirstName == this.FirstName && u.LastName == this.Last name ... ... u.Fetish = this.Fetish));
рефлексия медленная и не даст контроля над списком сравниваемых полей. А вообще Equals переопределять не надо, ни к чему хорошему это не приведёт.
рефлексия может применяться шарпами даже там, где ты сам не хотел этого, например равнение 2х структур где есть ссылочные параметры и нет перегрузки для сравнения
я поэтому и написал, что не эффективно, но если используется не часто, то допустимо, особенно если полей дофига, и они будут добавляться, проще пометить атрибутом нужные поля и оставить все на рефлексию, чем лесть и править портянки
твой вариант я и сам использую если код для себя, но это один хер огромная портянка неудобная для чтения
я поэтому и написал, что не эффективно, но если используется не часто, то допустимо, особенно если полей дофига, и они будут добавляться, проще пометить атрибутом нужные поля и оставить все на рефлексию, чем лесть и править портянки
твой вариант я и сам использую если код для себя, но это один хер огромная портянка неудобная для чтения
При сравнении двух структур со ссылочными полями значения полей будут сравниваться по ссылке, а не по значению.
гдето читал, что шарп видя в структуре ссылочные поля начинает елозить рефлексией, и думается мне, что если поля с поддержкой компараторов то шарп таки будет через них сравнивать, плохо уже помню
да и к томуже не знаю насколько ты пользовался рефлексией, но с ней можно делать все что душе угодно совместно с атрибутами, хоть в космос запускай
весь WPF это сплошная рефлексия, там плюнуть негде попадешь в рефлексию
можно запилить один хелпер, и иметь во все щели все объекты опятьже руля лишь атрибутами
весь WPF это сплошная рефлексия, там плюнуть негде попадешь в рефлексию
можно запилить один хелпер, и иметь во все щели все объекты опятьже руля лишь атрибутами
кстати вродекак тут если все параметры примитивы, и делать не класс а структуру, то шарп и так бинарно сравнит
Структуры в стеке хранятся, сравнить два их экземпляра не сложнее чем два инта.
Оператор Equals будет с высокой вероятностью вызываться массово и очень часто (в основном не твоими руками), так что незначительные потери легко станут значительными
Шарпец по умолчанию сравнивает объекты ссылочных типов по ссылкам, а объекты значимых типов -- по значению. А вообще шарп не любит всякие ссылки, указатели... прям как жаба.
так оно ж не должно компилироваться ашибка тут:if(!obj is user)
=> if(!(obj is user)
=> if(!(obj is user)
"А еще можно IF'ы распределить по `популярности` и получить на работе премию за оптимизацию" (с) Курсы "Специалист" по C
И ведь как раз недавно подобное говно делал...
пирамида валидации
Напомнило
Мне кажется или все забыли про хеши? Переопределяем _GetHashcode и по ним сравниваем два объекта... профит
Нельзя переопределять Equals не переопределяя GetHashCode и наоборот, т.к. это ломает работу библиотек C#, в частности LINQ, если с их помощью работать с таким объектом.
Я не говорил, что не надо перегружать Equals
тогда не ясен смысл вашего коммента. разве что он был саркастическим
Не говоря уже о том, что 1) два одинаковых хэш-кода не означают одинаковости объектов 2) в GetHashcode всё-равно придётся обращаться к каждому из полей
Чтобы написать коммент, необходимо залогиниться