Comments 15
хорошая статья и перевод на уровне, спасибо
Очень простое и понятное объяснение «вариантности» дженерик-коллекций было, кажется, у Рихтера (или я это в каком-то блоге встречал, не помню уже):
Каждая дженерик-коллекция по параметрам дженерика на этапе компиляции разворачивается свой уникальный тип.
По сути для виртуальной машины .NET не существует типа List
Каждая дженерик-коллекция по параметрам дженерика на этапе компиляции разворачивается свой уникальный тип.
По сути для виртуальной машины .NET не существует типа List
Это не так, дженерики существуют для CLR. И на этапе компиляции не преобразуются.
Угу, в любом случае, даже если бы пост был целиком, там была написана глупость.
Изучил подробнее и понял это.
Слажал, пинайте.
Изучил подробнее и понял это.
Слажал, пинайте.
И все-таки (реваншизм неистребим :) ):
CLR Via C# Second Edition, р.372 «Code Explosion»
When a method that uses generic type parameters is JIT-compiled, the CLR takes the method's
IL, substitutes the specified type arguments, and then creates native code that is specific to that
method operating on the specified data types. This is exactly what you want and is one of the
main features of generics. However, there is a downside to this: the CLR keeps generating native
code for every method/type combination. This is referred to as code explosion. This can end up
increasing the application's working set substantially, thereby hurting performance.
И все же итоговый результат — формируется отдельный код для методов, только не самим компилятором (он действительно компилирует дженерик в IL код именно как неспецифицированный класс), а JIT. И как результат — native код для типов двух Generic реализаций, даже специфицированных полиморфными типами — разный.
К конкретному объяснению причин отсутствия ковариантности в ранних C# это имеет не близкое отношение.
В процессе изучения, кстати возник интересный вопрос и ответ на него:
Какое поведение будет у двух экземпляров, например List, когда они будут загружены в разные домены и из одного домена будет обращение к другому?
Если я правильно понял, то при кросс-доменом обращении объект-прокси сообразит что у собственного Listи у того что в соседнем домене (к которому он и проксирует) одинаковые экземплярные члены и разрешит присвоение Listиз другого домена к собственному List.
Хотя это еще надо проверить, у Рихтера все же в примере простые типы, не generic.
CLR Via C# Second Edition, р.372 «Code Explosion»
When a method that uses generic type parameters is JIT-compiled, the CLR takes the method's
IL, substitutes the specified type arguments, and then creates native code that is specific to that
method operating on the specified data types. This is exactly what you want and is one of the
main features of generics. However, there is a downside to this: the CLR keeps generating native
code for every method/type combination. This is referred to as code explosion. This can end up
increasing the application's working set substantially, thereby hurting performance.
И все же итоговый результат — формируется отдельный код для методов, только не самим компилятором (он действительно компилирует дженерик в IL код именно как неспецифицированный класс), а JIT. И как результат — native код для типов двух Generic реализаций, даже специфицированных полиморфными типами — разный.
К конкретному объяснению причин отсутствия ковариантности в ранних C# это имеет не близкое отношение.
В процессе изучения, кстати возник интересный вопрос и ответ на него:
Какое поведение будет у двух экземпляров, например List, когда они будут загружены в разные домены и из одного домена будет обращение к другому?
Если я правильно понял, то при кросс-доменом обращении объект-прокси сообразит что у собственного Listи у того что в соседнем домене (к которому он и проксирует) одинаковые экземплярные члены и разрешит присвоение Listиз другого домена к собственному List.
Хотя это еще надо проверить, у Рихтера все же в примере простые типы, не generic.
обрезался кусок поста и получилась бессмысленная фигня. Извините :(
С out всё достаточно просто.
Но я наконец-то понял что значит in в интерфейсе, вернее как это можно применить :o)
Ещё бы побольше примеров на это.
Но я наконец-то понял что значит in в интерфейсе, вернее как это можно применить :o)
Ещё бы побольше примеров на это.
А будет ли работать пример с Action,
если void Manipulate(object obj) заменить на void Manipulate(string obj)
и почему?
если void Manipulate(object obj) заменить на void Manipulate(string obj)
и почему?
Нет.
Вообще есть простое правило. Если используется out то один тип может быть заменён на более общий (Listзаменяется на List
Вообще есть простое правило. Если используется out то один тип может быть заменён на более общий (Listзаменяется на List
ой: о)
Если используется out то один тип может быть заменён на более общий (List<string> заменяется на List<object>)
С in всё наоборот. Если используется in то один тип может быть заменён на более конкретный (void Action(object) заменяется на void Action(string))
Если используется out то один тип может быть заменён на более общий (List<string> заменяется на List<object>)
С in всё наоборот. Если используется in то один тип может быть заменён на более конкретный (void Action(object) заменяется на void Action(string))
C out все ясно, как быть с in?
Как я понял Action определен как Action<in T>
Как я понял Action определен как Action<in T>
Sign up to leave a comment.
C# 4.0 и вариантность