Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
У вас в таблице опечатка - record struct с позиционной записью можно создавать с помощью инициализатора объектов. Вообще конструкторы и инициализаторы объектов ортогональны друг другу в каком-то смысле -- если объект создался с помощью какого-то конструктора (а у record struct есть дефолтный конструктор), те его поля и set/init свойства, которые видны в данном контексте можно присвоить в инициализаторе. В том числе, можно сначал инициализировать свойство в конструкторе и тут же пере-присвоить значение в инициализаторе.
Вообще, огромные вопросы к шпаргалкам в конце. Особенно к выбору, что использовать, рекорды или обычные классы/структуры. Это слабо связано с тем, будет ли использоваться тип в качестве поля другого типа. Обычные структуры чаще всего используются для оптимизаций, где можно избавиться от лишних аллокаций в куче и ускорить операции (как пример, особая поддержка struct-энумераторов в foreach или при ручном вызове для массивов, спэнов, и т.д.), record struct теперь по всей видимости будут представлять value-type DTO с хэшем, равенством, и т.д. (все эти ваши Point2D, RGB цвета и т.д., для чего раньше приходилось руками писать весь обвес). record это теперь go-to решение для доменных моделек и прочих value-object из-за иммутабельность по умолчанию и простоты создания, а так же из-за наследования. Ну и class на все остальное, включая EF, которому плохо от иммутабельных рекордов.
И 16 байт тут тоже так себе лимит. В зависимости от функций вашего кода, предача readonly record struct по in ссылке или не-readonly по ref (в зависимости от целей) может быть гораздо эффективнее чем использование ссылочного типа.
Короче, наверное каждая шпаргалка подлежит обсуждению.
Бенчмарк очень сомнительный. Оптимизатор видит, что ссылка на объект не выходит за пределы цикла и может либо переиспользовать объект, либо вовсе его не создавать. Правильный бенч — это создать список из 1e6 объектов, проинициализировав их, а вторым циклом пройтись по коллекции и просуммировать поля.
В статье столько огрехов, что я бы её отьсюда убрал, чтобы не вводить незнающих людей в заблуждение.
Навскидку:
1) Ни record ни record struct не являются какими-то новыми типами данных. Это просто синтаксические конструкции которые компилятор превращает в самые обычные классы и структуры просто с дополнительным автоматически сгенерированным функционалом который.
2) Entity Framework и JSON давным-давно отлично понимают конструкторы с параметрами.
3) Совершенно не упомянуты readonly struct и readonly record struct про которые здесь надо было, конечно, написать.
4) И самое главное. У всех кто делает мутабельные структуры надо на лбу большими буквами писать: "Структура ВСЕГДА должна быть иммутабельной". Потому что количество граблей на которые можно наступить при использовании изменяемых структур просто неисчислимо
Согласен с вышесказанным.
Со структурами в любом виде много граблей. `struct` - это по сути оптимизация и ничего больше. Поэтому стоит как следует подумать, не является ли она преждевременной в каждом конкретном случае.
С пунктом 4 абсолютно согласен. Как-то до недавнего времени не доводилось работать с проектами старше core 3.1. И со структурами знаком только по F#. Из-за этого в голове отложилось, что структуры всегда иммутабельны. А в C# вон оно как на самом деле
А есть где-то общий список граблей изменяемых структур? Для памяти, потому как struct в кровавом энтерпрайзе вещь нечастая.
Вот ведь развели зоопарк из типов..
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Record vs struct — когда кто кого