Почему изменчивые структуры «злые»?
class Program
{
List listOfEmp = new List();
List listOfDepart = new List();
public Program()
{
listOfDepart = new List(){
new Department { Id = 1, DeptName = "DEV" },
new Department { Id = 2, DeptName = "QA" },
new Department { Id = 3, DeptName = "BUILD" },
new Department { Id = 4, DeptName = "SIT" }
};
listOfEmp = new List(){
new Employee { Empid = 1, Name = "Manikandan",DepartmentId=1 },
new Employee { Empid = 2, Name = "Manoj" ,DepartmentId=1},
new Employee { Empid = 3, Name = "Yokesh" ,DepartmentId=0},
new Employee { Empid = 3, Name = "Purusotham",DepartmentId=0}
};
}
static void Main(string[] args)
{
Program ob = new Program();
ob.LeftJoin();
Console.ReadLine();
}
private void LeftJoin()
{
listOfEmp.GroupJoin(listOfDepart.DefaultIfEmpty(), x => x.DepartmentId, y => y.Id, (x, y) => new { EmpId = x.Empid, EmpName = x.Name, Dpt = y.FirstOrDefault() != null ? y.FirstOrDefault().DeptName : null }).ToList().ForEach
(z =>
{
Console.WriteLine("Empid:{0} EmpName:{1} Dept:{2}", z.EmpId, z.EmpName, z.Dpt);
});
}
}
class Employee
{
public int Empid { get; set; }
public string Name { get; set; }
public int DepartmentId { get; set; }
}
class Department
{
public int Id { get; set; }
public string DeptName { get; set; }
}
7 ответов
Структуры являются типами значения, что означает, что они копируются, когда они розданы.
Поэтому при изменении копии, Вы изменяетесь только, что копия, не оригинал и не любые другие копии, которые могли бы быть вокруг.
, Если Ваша структура неизменна затем, все автоматические копии, следующие из того, чтобы быть переданным значением, будут тем же.
, Если Вы хотите изменить его, необходимо сознательно сделать это путем создания нового экземпляра структуры с измененными данными. (не копия)
-
1У меня есть подобная проблема, которая происходит из-за наличия нескольких NSManagedObjectContext' s для многопоточного базового кода данных. Где Вы предлагаете, чтобы я искал проблемы поточной обработки? – Jason 13 November 2012 в 18:39
Существует много преимуществ и недостатков к изменяемым данным. Недостаток за миллион долларов искажает. Если то же значение будет использоваться в нескольких местах, и один из них изменяет его, то это, будет казаться, волшебно изменилось на другие места, которые используют его. Это связано с, но не идентичное с, условия состязания.
преимуществом за миллион долларов является модульный принцип, иногда. Изменяемое состояние может позволить Вам скрывать изменяющуюся информацию от кода, который не должен знать об этом.
Искусство Интерпретатора входит, они торгуют offs в некоторых деталях, и дает некоторые примеры.
Это doesn’t имеют какое-либо отношение к структурам (а не с C#, любым), а в Java, Вы могли бы получить проблемы с изменяемыми объектами, когда они, например, вводят карту хеша. Если Вы изменяете их после добавления их к карте, и оно изменяет хэш-код , злые вещи могли бы произойти.
-
1Я должен сказать, что
saveContextиспользованиеperformBlockAndWait:самостоятельно, так должно быть безопасно использовать здесь, если я понимаю типы параллелизма очереди правильно... – DaGaMs 31 March 2013 в 06:15
Типы значения в основном представляют неизменные понятия. Fx, не имеет никакого смысла иметь математическое значение, такое как целое число, вектор и т.д. и затем мочь изменить его. Это было бы похоже на переопределение значения значения. Вместо того, чтобы изменить тип значения, имеет больше смысла присваивать другое уникальное значение. Думайте о том, что типы значения сравнены путем сравнения всех значений его свойств. Дело в том, что, если свойства являются тем же затем, это - то же универсальное представление того значения.
, Поскольку Konrad упоминает, что не имеет смысла изменять дату или, поскольку значение представляет тот уникальный момент времени и не экземпляр объекта времени, который имеет любое состояние или зависимость контекста.
Надежды это имеет любой смысл Вам. Это больше о понятии, которое Вы пытаетесь получить с типами значения, чем практические детали, быть уверенными.
-
1Этот ответ помог мне найти решение в своем случае, где очень похожая вещь происходила на различном проекте, который я пытался преобразовать из 32 до 64 битов. Оказывается I' d избежал преобразовывать явный/machine:X86, устанавливающий в Дополнительных опциях на/machine:x64 – Roger Attrill 26 March 2012 в 01:55
Где запустить; блог -p
Eric Lippert всегда хорош для кавычки:
Это - еще одна причина, почему изменяемые типы значения являются злыми. Попытайтесь всегда сделать типы значения неизменными.
Первый, Вы склонны терять изменения довольно легко..., например, вытаскивая вещи из списка:
Foo foo = list[0];
foo.Name = "abc";
, что это изменяло? Ничто полезное...
то же со свойствами:
myObj.SomeProperty.Size = 22; // the compiler spots this one
принуждение Вас сделать:
Bar bar = myObj.SomeProperty;
bar.Size = 22;
myObj.SomeProperty = bar;
менее критически, существует проблема размера; изменяемые объекты склоняются , чтобы иметь несколько свойств; уже, если у Вас есть структура с два int с, string, DateTime и bool, можно очень быстро гореть через большую память. С классом несколько вызывающих сторон могут совместно использовать ссылку на тот же экземпляр (ссылки являются небольшими).
Я не сказал бы , зло , но переменчивость часто является знаком очень обеспокоенности со стороны программиста для обеспечения максимума функциональности. В действительности это часто не нужно, и это, в свою очередь, делает интерфейс меньшим, легче использовать и тяжелее использовать неправильно (= более устойчивый).
Одним примером этого является чтение-запись и конфликты записи/записи в условиях состязания. Они просто не могут произойти в неизменных структурах, так как запись не является допустимой операцией.
кроме того, я утверждаю, что переменчивость почти никогда не на самом деле необходима , программист всего думает , что она могла бы быть в будущем. Например, просто не имеет смысла изменять дату. Скорее создайте новую дату, базирующуюся от старой. Это - дешевая операция, таким образом, производительность не является соображением.
-
1
Представьте, что у вас есть массив из 1 000 000 структур. Каждая структура, представляющая капитал с такими вещами, как bid_price, offer_price (возможно, десятичные дроби) и т. Д., Создается C # / VB.
Представьте, что массив создается в блоке памяти, выделенной в неуправляемой куче, так что какой-то другой поток машинного кода может одновременно обращаться к массиву (возможно, какой-то высокопроизводительный код выполняет математические вычисления).
Представьте, что код C # / VB слушает рыночный поток изменений цен, этот код может получить доступ к некоторому элементу массива (для какой бы безопасности), а затем изменить какое-то поле (поля) цены.
Представьте, что это происходит десятки или даже сотни тысяч раз в секунду.
Давайте посмотрим правде в глаза, в данном случае мы действительно хотим, чтобы эти структуры были изменяемыми, они должны быть такими, потому что они используются другим нативным кодом, поэтому создание копий не поможет; они должны быть такими, потому что создание копии какой-то 120-байтовой структуры с такой скоростью - безумие, особенно когда обновление может фактически повлиять только на один или два байта.
Хьюго