Comments 25
Извините за духоту, но на самом деле, лучше выучить термин делегат, ознакомиться с тем что такое предикат, и использовать документацию Майкрософт. По крайней мере, от .net разработчика ожидаешь этого.
https://learn.microsoft.com/en-us/dotnet/csharp/linq/get-started/introduction-to-linq-queries
и использовать документацию Майкрософт
Разработчику не нужно уметь читать.
Объемный труд.
А я помню времена, когда он только появился. Появилась возможность мыслить множествами, как в SQL. Некоторые задачи лучше решаются таким способом.
И ни слова про ленивость. Как человек должен писать код, не понимая как этот код выполняется? Результатом работы методов LINQ является не коллекция, а IEnumerable, за которым скрывается метод - генератор коллекции. Не понимая этого, можно такого наворотить...
var result4 = nums.SelectMany( n => chars.Select( c => c + n.ToString() ));
Не совсем корректный пример для метода SelectMany. Получается просто вложенный Select, а SelectMany делает из вложенных последовательностей одну единую. Правильнее и нагляднее было бы сделать вот так:
var result4 = nums.SelectMany(n => chars, (n, c) => c + n.ToString());Также очень хотелось бы увидеть примеры с методом Aggregate, ибо без него просто никуда. Банально тот же BigInteger не имеет других методов агрегации, кроме него. Да и вообще с ним можно много всего наворотить. )
Очень хорошо Linq разобран в книге Джозефа Албахари "C# 9.0. Справочник. Полное описание языка" (Joseph Albahari "C# 9.0 IN A NUTSHELL. THE DEFINITIVE REFERENCE").
Спасибо за полезное замечание. Для SelectMany в статье два примера. Первый пример иллюстрирует реализацию вложенного цикла, а второй - склеивание коллекций.
Метод Aggregate упомянут в конце статьи, без примеров, т.к. статья предназначена для первоначального знакомства, это не полноценный учебник по LINQ.
У Албахари я читал "LINQ. Карманный справочник", там хорошо все разжевано.
Очень спорное утверждение, вот я за более 10 лет программирования на C# использовал метод Aggregate может раза 2 от силы. Вместо Aggregate обычно проходитесь по перечислению через foreach и днлаете любые преобразования и аггрегируете как хотите
Aggregate и StringBuilder отлично склеивают строки в очень лаконичном синтаксисе.
Как вы соедините строки из коллекции элементов через String.Concat?
Там по ссылке же примеры все есть.
ну вообще string.Join, concat тоже не использую, StringBuilder использую
string.Join он все-таки немного для другого - он чтобы соединить через разделитель, например, запятую. И я его тоже, конечно, использую. string.Concat он просто чтобы соединить строки без overhead, так же как и StringBuilder просто когда есть какая-то готовая коллекция строк, или просто несколько строк, то его часто удобней использовать.
Мне кажется, Вы неправильно описываете парадигму LINQ.
Вот, например:
var result2 = nums.Select( n => n+1 );Для каждого элемента в исходной коллекции nums
, используя переменную n для обозначения элемента коллекции nums,
добавить в результирующую коллекцию значение, полученное из выражения n+1.
Поместить результирующую коллекцию в переменную result2.
В том-то и дело, что в result2 ничего не помещается на данном этапе.
Тут описание, скорее, должно быть
result2 - это результат применения указанной функции к элементам коллекции nums.
Всё. Как именно LINQ перебирает элементы исходной коллекции, вообще не важно. Это детали реализации, которые, в теории, могут быть любые.
То же самое и с фильтрами - не нужно помещать или не помещать элемент в итоговую коллекцию. Результат работы Where это коллекция, содержащая только те элементы исходной, которые соответствуют предикату (проходят фильтр).
LINQ - он именно об этом. Декларативное описание.
Императивное "взять каждый элемент и что-то с ним сделать, поместить результат куда-то там" - это всё появляется (или не появляется) только когда вы материализуете результат каким-нибудь .ToArray() или foreach.
Погрузитесь немного глубже в тему, это не сложно, это интересно.
Спасибо за полезное замечание. Добавил в текст описание отложенного выполнения. Статья предназначена для первоначального знакомства с LINQ, поэтому старался всё упростить по максимуму.
IQueryable это вообще отдельная история. Другие типы, другой принцип работы. Просто общий внешний вид
Статьи о том как использовать, обычно неполны без пояснений: зачем использовать. То есть о плюсах и минусах.
И было бы не лишним упомянуть про альтернативные реализации linq, типа SimdLinq. И снова: зачем нужны и чем заплатим.
Не имею ничего против, но мне лично вообще непонятно зачем описывать вещи и так хорошо изложенные на протяжении последних 10 лет в том числе в документации. Ну и вы не сказали главного: если вы хотите действительно быстро - то надо держаться подальше от LINQ. И если есть условное его использование - НАДО разбивать на методы. Почему? Секрет. Все это знают, но вам это не интересно.
TLDR: Нормальный код вообще никогда не должен использовать LINQ. Он как был днищем так и таким есть.
TLDR: Нормальный код вообще никогда не должен использовать LINQ. Он как был днищем так и таким есть.
С вами не согласны я и все мои коллеги под .NET.
если вы хотите действительно быстро - то надо держаться подальше от LINQ.
А вы в курсе о поддержке AVX инструкций методами LINQ?
Встречались мне проекты где вот такой вот лид (обычно дядька в возрасте или прочитавший какую то очень спорную статью) выдвигает странные требования к коду. Типа linq тормозит, его использовать нельзя. Или "int" непонятно и неоднозначно, надо везе писать "Int32" или return в методе должен быть только один, или никаких using без фигурных скобок или никаких автопропертей. И главное что для всех таких заморочек есть какое то обоснование, такое же замороченное и абстрактное. Но тимлид сказал и все, пляшем именно так.
«Быстрое свидание» с LINQ