Комментарии проекта Программирование
7

C# Делегаты и события

» Программирование
В данной статье рассматриваются базовые операции над делегатами, их производными и связующими.

Читать далее...
Devion #1 - 4 недели назад (отредактировано ) 0
даже базовый тип ничего не сделает, т.к. под капотом '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, и уже эту переменную прокинуть в лямбду, в этом случае будет создаваться отдельный экземпляр делегата каждый виток цикла (но в старых версиях компилятора это будет работать иначе, что вроде как баг, ибо для пользователя оно по факту должно выглядеть как "передача ссылки").
Бтв, тут всплывает тема с аллокацией, т.к. как ты можешь заметить создание экземпляра каждый виток цикла это дичь )
ScorpioT1000 #2 - 4 недели назад (отредактировано ) 0
Про последнее, оно замыкает по ссылке даже базовый тип? Хотя вроде это везде так вроде, кроме пхп и вроде c++11, там надо явно указать.
Devion #3 - 4 недели назад 0
Имхо еще что можно сделать по теме, чуть посложнее чем для новичков, но интересно:
# объяснить подробнее про вычитание списка делегатов
Например, разъяснить почему:
  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();
ScorpioT1000 #4 - 4 недели назад 0
Функшн поинтеры в С++ вполне себе типобезопасны.
То же хотел сказать) либо имели ввиду C поинтеры
Msey #5 - 4 недели назад 0
Doc:
С с++ не работал, поэтому, с учетом отсутствия примера, опровергающего это:
Delegates are like C++ function pointers but are type safe.
Я остановлюсь на мсдн'овском варианте.
Doc #6 - 4 недели назад 4
Делегаты похожи на указатели функций в C++, но являются объектно-ориентированными и типобезопасными
Понимаю, что перевод с МСДН, но бред. Функшн поинтеры в С++ вполне себе типобезопасны.
Isstrebitel #7 - 4 недели назад (отредактировано ) 0
За ковариантность и контравариантность огромное спасибо, месяца два назад наткнулся именно на такое, где прекрасно понимал, что "вот бы такое было" - без этого было крайне неудобно, но не знал, что такое есть и так называется.
Даже не помню уже, почему у меня такое не получалось, должен же был хоть попробовать
А с тех пор только на плюсах писал, вот так вот -_-
16

Работа с файлами конфигурации приложения

» Программирование
В данной статье будет разобраны основы работы с конфигурационными файлами, секциями конфигурации и созданием своих конфигурационных разделов. Перед прочтением рекомендуется ознакомиться с языком разметки xml, индексаторами, свойствами, приведением типов и всем C# в целом.

Читать далее...
ScorpioT1000 #1 - 1 месяц назад 0
Devion, его форсили, т.к. была libxml, а кроме неё ничего не было, только всякие бомжовские ini
Devion #2 - 1 месяц назад (отредактировано ) 3
Про геймдев я сказал, т.к. это широкая стенд-элон индустрия, в вебе и сетевых аппликухах 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.
ZlaYa1000 #3 - 1 месяц назад 0
ScorpioT1000, который из yml? под таким разрешением несколько форматов
ScorpioT1000 #4 - 1 месяц назад (отредактировано ) 0
Эргалон, да, комментарии в жсон не предусмотрены, т.к. он изначально был для передачи данных по сети. Зато они есть в yml, как ранее уже описывали. yml лучше подходит для конфигурации, но он всё ещё мало поддерживается старпёрскими библиотеками.
В самой статье ни слова не было о геймдеве
Про геймдев я сказал, т.к. это широкая стенд-элон индустрия, в вебе и сетевых аппликухах xml уже давно пережиток прошлого, за исключением некоторых протоколов (хотя нет, привет андроиду и жаве с их вьюхами)
Hellfim #6 - 1 месяц назад 0
ScorpioT1000, А теперь прокомментируй каждую строку в джейсоне своем
Это, конечно, классно просить сделать то, для чего формат не предназначен.
и покажи редактор, который грамотно выделит синтаксис)
Notepad++ более чем достаточно
Может он и подойдет, для более маленьких конфигураций, а если у тебя конфигурация на 1000+ строк? Как ты будешь потом разгребаться, что есть где?
Ровно также как и в xml, только в xml больше тегов стоит.
писать отдельную библиотеку чисто ради единоразового чтения параметров как минимум глупо
Ну да, Newtonsoft подключить к проекту нельзя. Нужно что-то своё навелосипедить :)
alexprey #7 - 1 месяц назад 0
тк большинство конфигураций для расширений (логгеры, фреймворки итд) инжектятся именно в xml формате
щто, оно же через тот же конфигуратор грузится.
Msey #8 - 1 месяц назад (отредактировано ) 0
ScorpioT1000:
  • В самой статье ни слова не было о геймдеве, а ключевое слово под статьей unity3d чисто ради кликбейта
  • Сейчас речь идет конкретно о платформе .net, где xml - штатный язык разметки, и писать отдельную библиотеку чисто ради единоразового чтения параметров как минимум глупо (это без учета того, что конфигурационными файлами пользуются зачастую заказчики, и они могут по физиономии настучать за такие вот распространенные конфиги)
В тех проектах, за которые мне чаще всего не платят, я обычно самописными конфигами пользуюсь
Эргалон #9 - 1 месяц назад (отредактировано ) 0
ScorpioT1000, А теперь прокомментируй каждую строку в джейсоне своем и покажи редактор, который грамотно выделит синтаксис)
Может он и подойдет, для более маленьких конфигураций, а если у тебя конфигурация на 1000+ строк? Как ты будешь потом разгребаться, что есть где?
Devion #10 - 1 месяц назад 0
не знаю что за yml, знаю yaml.
для сложных типов данных как раз не xml а yaml, т.к. это больше чем разметка, есть поддержка алиасов специально для сериализации ссылочных типов
ScorpioT1000 #11 - 1 месяц назад -1
Msey, а в геймдеве принято не читать документацию?
Msey #12 - 1 месяц назад 0
ScorpioT1000:
Ох уж этот xml) там на жсон ещё не торопятся в геймдеве переходить?
На самом деле это проблемный вопрос, тк большинство конфигураций для расширений (логгеры, фреймворки итд) инжектятся именно в xml формате, и чтобы убедиться, что они читают конфиги в нескольких форматах, нужно, либо читать документацию, либо в случае ее отсутсвия чекать рефлектором.
По крайней мере в дотнете
ScorpioT1000 #13 - 1 месяц назад (отредактировано ) 0
Эргалон, лолшто, приведи примеры
{
	"configuration": {
		"configSections": {
			"section": {
				"name": "customSection",
				"type": "System.Configuration.NameValueSectionHandler"
			}
		},
		"startup": {
			"supportedRuntime": {
				"version": "v4.0",
				"sku": ".NETFramework,Version=v4.6.1"
			}
		},
		"customSection": {
			"add": {
				"key": "KeyFromCustomSection",
				"value": "valueFromCustomSection"
			}
		}
	}
}
H #14 - 1 месяц назад 0
xml формат не для хранения конфигов имхо, а для передачи сложных типов данных (объектов и т.п.). Есть же json/yml или хотя-бы ini.
xml
<appSettings>
      <add key="KeyA" value="Msey" />
      <add key="KeyB" value="Love" />
      <add key="KeyC" value="Goosey" />
</appSettings>
json
{
  "appSettings": {
    "KeyA": "Msey",
    "KeyB": "Love",
    "KeyC": "Goosey",
  }
}
yml
appSettings:
  KeyA: Msey
  KeyB: Love
  KeyC: Goosey
ini
[appSettings]
KeyA=Msey
KeyB=Love
KeyC=Goosey
Эргалон #15 - 1 месяц назад 0
ScorpioT1000, JSON для конфига не лучший вариант. В том плане, что xml в этом плане гораздо лучше читаемый и регулируемый.
ScorpioT1000 #16 - 1 месяц назад (отредактировано ) 0
Ох уж этот xml) там на жсон ещё не торопятся в геймдеве переходить?
24

Интерфейсы и с чем их едят

» Программирование
В этой статье буду рассмотрены основные моменты при использовании интерфейсов.
Перед прочтением рекомендуется ознакомиться с наследованием классов и преобразованиями типов объекта.

Читать далее...
Msey #1 - 1 месяц назад 1
Batnik:
Будут еще статьи про C#?
Да. Я как раз над этим работаю.
Просто щас тут еще и понкурс по картам вк3 и времени мало остается, но статьи будут!
*конкурс
Hate #2 - 1 месяц назад 3
Batnik:
Будут еще статьи про C#?
будут
Batnik #3 - 1 месяц назад 2
Будут еще статьи про C#?
GeneralElConsul #4 - 2 месяца назад 0
Да банально позволяет "выдергивать" из класса только тот функционал, который нужен.
lentinant #5 - 2 месяца назад 1
Важное свойство интерфейса в том, что он ограничивает доступ к реализации класса. Классу А, работающему со сложным классом Б, не обязательно знать о всех методах и свойствах класса Б. Однако, если класс Б реализовывает определенный интерфейс, класс А может об этом знать, и вместо того чтобы работать с многочисленными методами класса Б, он может общаться с ним через интерфейс, получив доступ только к тем методам, которые ему важны.
Есть даже простой пример на реальных объектах - корпус вашего системника. Внутри системника куча функционала, разъемов, проводов и т.д., однако сам корпус обеспечивает вам доступ к самым важным элементам - кнопкам управления и выходам для различных девайсов. Представьте себе если бы порт USB находился на самой материнке, и чтобы найти его, вам приходилось бы высматривать его с десятков других разъемов на материнке.
nvc123 #6 - 2 месяца назад (отредактировано ) 1
GeneralElConsul, интерфейс это класс в котором все методы абстрактные и публичные (и прочие искусственные фичи наподобие множественного наследования)
но тут судя по вопросу человек не понимает не в чём отличие абстрактного класса от интерфейса а применение полиморфизма
Doc #7 - 2 месяца назад 2
Ну отсутствие состояния и реализации методов (что и позволяет множественно наследоваться) и отличает интерфейс от абстрактного класса.
GeneralElConsul #8 - 2 месяца назад (отредактировано ) 0
Да просто человек сказал, что он не понимает смысл интерфейсов, а вы ему давай писать то, для чего и обычный абстрактный класс сгодиться, не затрагивая сути его существования - так он точно не изменит свою точку зрения.
nvc123 #9 - 2 месяца назад (отредактировано ) -1
Doc, тут люди не понимают зачем нужен полиморфизм а ты про контракты и состояния
ну а вообще если говорить простым языком (т.е. для полных нубов) то интерфейсы нужны для того чтобы убедится что класс имеет реализацию необходимых методов
Doc #10 - 2 месяца назад 6
Множественное наследование просто побочный эффект. Интерфейс просто объявляет контракт. Важное свойство интерфейса в том что он не имеет собственного состояния.
GeneralElConsul #11 - 2 месяца назад 2
Хм, а давайте подумаем, почему Майкрософт сделали и интерфейс IComparer, и класс Comparer. Ну да, наверное, чтобы в случае класса его наследовали когда хочется унаследовать именно класс (настроение такое - хочу наследовать классы сегодня!). А в случае интерфейса - когда, увы, уже наследуешь один класс и для второго класса места нет, поэтому есть возможность наследовать интерфейс.
Ведь вся суть использования интерфейсов именно в том, что именно для них поддерживается множественное наследование, да.
uranus #12 - 2 месяца назад 2
GeneralElConsul, класс наследуется один, интерфейсов может быть множество, миксинов в шарпе нет, я не понимаю, с чего тут разводить дискуссию.
GeneralElConsul #13 - 2 месяца назад (отредактировано ) 0
Конкретно то, что вы в вверху описали можно сделать и наследованием класса.
NanO #14 - 2 месяца назад 0
Как не видел смысла в интерфейсах, так и не вижу. Там где нужна та или иная реализация в классе, она там и будет. Даже если несколько объектов, должны уметь делать что-то одно, это будет объявлено и без интерфейсов.
Ясно-понятно.
Msey #15 - 2 месяца назад (отредактировано ) 0
Интерфейсы можно конечно заменить одним помойным абстрактным классом, но по мне - это уже признак говнаря, если дело касается чего-то серьезного с использованием solid, тестирования итд
Со временем это понимается
nvc123 #16 - 2 месяца назад 0
как пример интерфейсы юзаются в шаблоне observer/listener
да и вообще большинство шаблонов проектирования использует интерфейсы
uranus #17 - 2 месяца назад (отредактировано ) 0
Эргалон, иногда объекты слишком разные, поэтому наследование классов не подходит, но в то же время за счет наследования интерфейсов можно будет хранить их в одних массивах/коллекциях, наделять их неким сходством.
» Как-то так
public interface IDrawable {
	void Draw(Graphics render);
}

public class Rectangle : IDrawable {
	...
	public void Draw(Graphics render) {
		render.DrawRectangle(pen,x,y,w,h);
	}
}

public class Shape : IDrawable {
	...
	public void Draw(Graphics render) {
		render.DrawEllipse(pen,x,y,w,h);
	}
}

...
List<IDrawable> gameObjects;
....
Graphics g = Graphics.FromImage(canvas);
while (gameLoop) {
	g.Clear(color);
	foreach (var go in gameObjects) {
		go.Draw(g);
	}
}
При этом разные элементы могут наследовать от разных классов, какой-нибудь Label от UI, например, но объединяет их всех интерфейс IDrawable т.е. возможность прорисовки.
abidin #18 - 2 месяца назад 0
Как не видел смысла в интерфейсах, так и не вижу. Там где нужна та или иная реализация в классе, она там и будет. Даже если несколько объектов, должны уметь делать что-то одно, это будет объявлено и без интерфейсов.
Никто и не обязывает тебя пользоваться ими. Просто видимо ты ещё не нашёл такой задачи , где будут полезными только интерфейсы.
Ну хотя бы с IEnumerator ты хоть раз имел дело =)
Doc #19 - 2 месяца назад 2
Каким образом это будет объявлено без интерфейсов?
Эргалон #20 - 2 месяца назад (отредактировано ) 0
Как не видел смысла в интерфейсах, так и не вижу. Там где нужна та или иная реализация в классе, она там и будет. Даже если несколько объектов, должны уметь делать что-то одно, это будет объявлено и без интерфейсов.
BrEd Pitt #21 - 2 месяца назад 3
спасибо за статью, просто и по полочкам, квик гайд фо даммиз лайк ми. Более развернуто, чем в "с# за 31 день"
Msey #22 - 2 месяца назад 2
RealizationABC
Может все-таки Implementation?
Да. Исправил.
Doc #23 - 2 месяца назад 6
RealizationABC
Может все-таки Implementation?
ZlaYa1000 #24 - 2 месяца назад 2
А чего никто не комментирует?)
2

Не могу выбрать движок.

» Программирование
Хотел бы слепить такой серверный мультиплеер:
•Игроки имеют обзор от 1/3 лица и могут выложить предмет (физика не обязательна), главное чтоб сервер запоминал каждый раз при выключении на какое место положили вещь и чтобы она там могла лежать вечно либо в контейнер.
•Физика и бои пойдут на уровне WoW.
•Админ сервера должен иметь возможность переключаться от обзора Сверху (как в стратегии) к 1/3 лицу и иметь возможность контрить пачки юнитов (как в WC3 к примеру).
Какой движок лучше подойдёт для этого?
GeneralElConsul #1 - 2 месяца назад (отредактировано ) 2
Насколько помню первоначальный вопрос - Unity или Unreal. Для этих целей подойдет и то, и то. На самом деле люди часто выбирают именно тот движок, который им больше нравиться, плюя на то, подходит он чуть больше или чуть меньше для их задач - если умеешь работать с двиглом, то сможешь сделать практически все. Поэтому желательно попробовать оба или хотя бы посмотреть видосы, понять, какой тебе нравиться.
А если говорить про удобство изучения с нуля, то, естественно, это Unity. Я бы рекомендовал начать пробовать с него. Если он тебе понравиться, то и пробовать Unreal смысла особого нет, тем более то, что ты писал в первоначальном варианте вопроса - чисто случай, для которого идеально подходит Unity.
pro100master #2 - 2 месяца назад 0
Если язык программирование сложен то Unity поможет если не хотите с нуля писать...
7

Аутентификация с нуля. Предотвратить подмену записей.

» Программирование
Столкнулся со специфичной проблемой безопасности при написании аддона для WoW.

Читать далее...
Zahanc #7 - 5 месяцев назад 0
все обращения к WoW API придется оставить не обфусцированными
Я как-то упустил этот момент. Благодарю за наводку.
обфускация имееет смысл только на больших объемах кода
Попробую декларировать десяток другой чуши в исходнике.
Закрою вопрос когда закончу с реализацией; пару недель. Спасибо за помощь.