I
если бы компилятор чётко знал, что есть некий struct энумератор с такими-то методами
Size: a a a
2020 December 22
I
в принципе, он и знает, но проблема что это интерфейс
P
Популярный пример: применение методов расширения Enumerable к массивам и спискам. У тебя есть массив, ты хочешь его отфильтровать и на выходе получить массив (или то же самое со списком). Тебе приходиться вызывать методы
Если бы в языке были тайп классы, а не интерфейсы, они возвращали бы тот же самый тип, к которому их применили.
ToArray или ToList в конце цепочки LINQ-методов.Если бы в языке были тайп классы, а не интерфейсы, они возвращали бы тот же самый тип, к которому их применили.
Where для массива возвращал бы массив.Ну хз хз, если идет цепочка преобразований, как раз не стоит перегенять в массивы промежуточные результаты
MS
В действительности, некоторые методы Enumerable проверяют типы переданного перечисления, чтобы оптимизировать скорость выполнения.
I
плюс не совсем ясно что с размером кода делать на самом деле - интерфейсы хоть и абстракция со своими перф минусами, они позволяют не генерировать код под каждый возможный энумератор
I
а ограничиться пусть более медленным, но компактным с точки зрения размеров кода механизмом
MS
плюс не совсем ясно что с размером кода делать на самом деле - интерфейсы хоть и абстракция со своими перф минусами, они позволяют не генерировать код под каждый возможный энумератор
У тайп-классов есть дефолтные реализации. Можно часть методов не писать вручную.
I
не, я про уже конечный машинный код)
I
по крайней мере если смотреть через призму дотнета и структур
I
и замены всех интерфейсов на тайпклассы со структурами
MS
Pavel
Ну хз хз, если идет цепочка преобразований, как раз не стоит перегенять в массивы промежуточные результаты
Производительность имеешь в виду? Да, в общем случае, ты прав. Ну вот, есть такой пример.
MS
не, я про уже конечный машинный код)
Тут не знаю. С этой точки зрения знатоки компиляторов лучше знают, можно это оптимизировать или нет.
VS
В действительности, некоторые методы Enumerable проверяют типы переданного перечисления, чтобы оптимизировать скорость выполнения.
вот кстати коллега на работе тоже буквально неделю назад так говорил) на поверку оказалось что практически никаких проверок нету
VS
непонятно откуда слух пошел)
I
ну почему, есть для некоторых методов
I
Например, Count всегда смотрит что под капотом, ICollection или нет
I
FirstOrDefault, LastOrDefault
VS
так это не тип проверяется, а кастится к разным интерфейсам
VS
нету такого что если массив,то так, а если лист то эдак
I
ну да, мне кажется это и имелось ввиду