даже базовый тип ничего не сделает, т.к. под капотом 'i' будет находиться в экземпляре делегата, и это будет один и тот же экземпляр во всех элементах списка.
На выходе компилятора будет примерно вот такое:
public void Do()
{
List<Action> actionList = new List<Action>();
DisplayClass displayClass = new DisplayClass();
for (displayClass.i = 0; displayClass.i < 3; displayClass.i++)
{
actionList.Add(new Action((object) displayClass, __methodptr(<Do>b__0)));
}
}
[CompilerGenerated]
private sealed class DisplayClass
{
public int i;
internal void <Do>b__0()
{
Console.Write((object) this.i);
}
}
т.к. вся лямбда внутри контекста захваченных переменных будет формировать отдельный класс то по факту замыкания не будет, если вынести лямбду в отдельный от цикла метод.
Так же можно создать переменную со значением и записать туда i, и уже эту переменную прокинуть в лямбду, в этом случае будет создаваться отдельный экземпляр делегата каждый виток цикла (но в старых версиях компилятора это будет работать иначе, что вроде как баг, ибо для пользователя оно по факту должно выглядеть как "передача ссылки").
Бтв, тут всплывает тема с аллокацией, т.к. как ты можешь заметить создание экземпляра каждый виток цикла это дичь )
Имхо еще что можно сделать по теме, чуть посложнее чем для новичков, но интересно:
# объяснить подробнее про вычитание списка делегатов
Например, разъяснить почему:
Action a = () => Console.Write("A");
Action b = () => Console.Write("B");
Action c = () => Console.Write("C");
Action s = a + b + c;
(s - (b + c))(); //A
//но при этом
(s - (a + c))(); //ABC
Упомянуть про порядок вычитания, например
s = a + b + a;
(s - a)(); //AB, а не BA
рассказать про аллокации, связанные с лямбдами, когда они происходят и почему, а так же почему то что оно аллоцирует может быть проблемой
например, как тут:
string str = "str1";
Action d1 = () => Debug.Log(str); //аллоцирует при каждом вызове метода, который объявляет d1
Action d2 = () => Debug.Log("str1"); //аллоцирует лишь однажды
рассказать про неявный захват переменных
Например объяснить, почему если очистить 'd1', 'a' останется в памяти до очистки 'd2'
var a = new object();;
var b = new object();
Action d1 = () =>
{
Debug.Log(a);
Debug.Log(b);
};
Action d2 = () => Debug.Log(b);
ну и про замыкания само собой, т.е. почему вот это выведет 333
var actions = new List<Action>();
for (int i = 0; i < 3; i++)
actions.Add(() => Console.Write(i));
foreach (var action in actions)
action();
За ковариантность и контравариантность огромное спасибо, месяца два назад наткнулся именно на такое, где прекрасно понимал, что "вот бы такое было" - без этого было крайне неудобно, но не знал, что такое есть и так называется.
Даже не помню уже, почему у меня такое не получалось, должен же был хоть попробовать А с тех пор только на плюсах писал, вот так вот -_-
В данной статье будет разобраны основы работы с конфигурационными файлами, секциями конфигурации и созданием своих конфигурационных разделов. Перед прочтением рекомендуется ознакомиться с языком разметки xml, индексаторами, свойствами, приведением типов и всем C# в целом.
Про геймдев я сказал, т.к. это широкая стенд-элон индустрия, в вебе и сетевых аппликухах xml уже давно пережиток прошлого, за исключением некоторых протоколов (хотя нет, привет андроиду и жаве с их вьюхами)
Файлы конфигурации в xml очень жестко навязывались в дотнетах. Например
app.config, который, как пример, мы создаем если хотим например зареплейсить какой-нибудь референс в зависимостях проекта
web.config
банально файлы sln и csproj
в ксамарине шаблоны форм (причем и под платформы и "свое" в таком виде)
вроде как MVC тоже что-то такое тянули, но не открывал давненько, боюсь ошибиться
файлы ресурсов всякие
WPF
WCF
если зайти на msdn и поглядеть там 90% вшитых файлов конфигураций xml
Видно, что сейчас от этого отходят, например .Net Core где солюшн уже в другом формате, или стандарт online темплейтов в json сделан, и на .Net Core можно переобъявлять старые app.config на другой лад
но как суть, более старые решения там навязывали xml, мб из-за вопросов совместимости.
Понятно что xml это синтаксически перегруженный кусок говна и юзать его намеренно на новых проектах то еще удовольствие, но момент относительно "всякого нативного" в дотнете еще актуален - то что постулируют писать в xml, пишется в xml.
PROGRAMMS
Комментарии проекта Программирование
[C#, Regex] Разделить строку на слова и цитаты
Выбор редакции
C# Делегаты и события
Ред. Devion
На выходе компилятора будет примерно вот такое:
Так же можно создать переменную со значением и записать туда i, и уже эту переменную прокинуть в лямбду, в этом случае будет создаваться отдельный экземпляр делегата каждый виток цикла (но в старых версиях компилятора это будет работать иначе, что вроде как баг, ибо для пользователя оно по факту должно выглядеть как "передача ссылки").
Бтв, тут всплывает тема с аллокацией, т.к. как ты можешь заметить создание экземпляра каждый виток цикла это дичь )
Ред. ScorpioT1000
# объяснить подробнее про вычитание списка делегатов
Например, разъяснить почему:
рассказать про аллокации, связанные с лямбдами, когда они происходят и почему, а так же почему то что оно аллоцирует может быть проблемой
рассказать про неявный захват переменных
ну и про замыкания само собой, т.е. почему вот это выведет 333
С с++ не работал, поэтому, с учетом отсутствия примера, опровергающего это: Я остановлюсь на мсдн'овском варианте.
Ред. Isstrebitel
Даже не помню уже, почему у меня такое не получалось, должен же был хоть попробовать
А с тех пор только на плюсах писал, вот так вот -_-
Выбор редакции
Работа с файлами конфигурации приложения
и всем C# в целом.Ред. Devion
но как суть, более старые решения там навязывали xml, мб из-за вопросов совместимости.
Понятно что xml это синтаксически перегруженный кусок говна и юзать его намеренно на новых проектах то еще удовольствие, но момент относительно "всякого нативного" в дотнете еще актуален - то что постулируют писать в xml, пишется в xml.