john2007Подскажите, зачем структуру DateTime сделали неизменяемой?

Изопропилушёл за попкорном

а чито, хороший вопрос. ждём набросов свенома на бедную DateTime.

хотя орхитектура DateTime и правда напростительно ужасна.

john2007А, я понял, кажется.

а в чем будет разница с
var dateTime = new DateTime(2014, 2, 30);
?

ошибка будет. и dateTime нельзя будет воспользоваться. а что делать с существующим dateTime, над которым вздумали поиздеваться?

john2007Тогда по другому, зачем структуры делать неизменяемыми?

чтоб их нельзя было изменять. например, из параллельного потока. и вообще, даже изменяемые структуры не такие уж изменяемые:




что увидем на экране?

john2007Или по проще пример, почему бы не сделать типа:

var d = new DateTime(2004, 12, 1);
d.AddYear(1);

нет, DateTime неизменяемый тип

изменяемый DateTime = много лишних и ненужных проблем, связанных в том числе с многопоточностью.
для неизменяемых типов компилятор может генерировать более оптимальный код.

cdtyjvНу это маразм. Обычный маразм. Так же они, например, сделали структурой Guid. Поэтому вы не можете, например, обнулить его. Вместо этого вам предлагается использовать default(Guid), который есть 000...000. Бред несусветный. Ну да ладно, таких перлов в .Net полно, не обращайте внимания.

john2007А какие проблемы у изменяемых структур с многопоточностью?

с тем, что один поток изменяет состояние структуры в то время, как другой поток считывает структуру, вы же помните, что структура передаётся по значению?

что по-вашему здесь должно произойти:

экземпляр нашей структуры:

DateTime dt;

поток 1 делает




в это же самое время поток 2 делает

john2007Но зачем маленькие структуры типа DateTime делать неизменяемыми? не понятно

ок, давайте подойдём с другой стороны.

вы знаете как устроена структура DateTime? хранятся ли там число, месяц, год, часы, минуты, секунды отдельно? или там хранится большое число в виде миллисекунд от начала эпохи, а свойства типа Year возвращают извлечённый результат? не знаете. потому что вас это не должно волновать. точна также разрабочиков не должно волновать то, что вы хотите менять параметры у времени. для этого вы создаёте новую структуру, если хотите что-то изменить, эта операция очень быстрая.

а теперь скажите пожалуйста, зачем вам потребовалось изменяемый DateTime? можете привести свою задачу, где это действительно нужно. а я в свою очередь постараюсь убедить вас, что это вам не нужно

john2007 Например у меня есть какой-то объект типа List, содержащий N элементов, кто-то хочет добавить элемент Add(Item) а я давай реализацию - new List, скопировал в него N элементов, добавил в него Item и вернул его как новый объект. Клева? ))

см. ниже.

john2007Создавать новую структуру при изменении все таки стоит времени, да и реализации тоже порой. Да и вообще в реальном коде это даже глупова-то будет выглядеть.

нет, это очень-очень быстро. вряд ли прямое изменение свойств DateTime было бы быстрей. а на счёт глупо не глупо, я не вижу в чём глупо, это всего лишь синтаксис.

john2007Но структуры типа int, decimal, DateTime передаются как правило по значению (можно обеспечить прием по значению), по этому мультипоточных проблем у них не возникает.

вот именно, что по значению. структура хранит несколько полей. один поток копирует всё значение в то время, как другой поток меняет часть всего значения. т.е. проблемная ситуация. а проблебные ситуации лучше устранять.

john2007Вот я и думаю, то что выделил жирным это разве good practice ? ))

где-то иначе и быть не может. но сравнение не очень адекватное. List это класс, а про экземпляры классов (доступные по ссылке) мы сейчас вообще не говорим.