Как стать автором
Обновить

Комментарии 41

3) Б, благодаря оптимизации компилятором. Он распознает такой паттерн и генерирует для него оптимальный код.
4) Оба операнда могут быть равны null для ссылочных типов.
6) Есть, если использовать GetInvocationList у MulticastDelegate и делать вызовы самому чере foreach -> Invoke.
4) — это разница, или я чего-то не понял…
С четвертым наврал — думал, вопрос про разницу между статической реализацией Compare и объектной CompareTo.
5) Реализация интерфейса определена как explicit и для выполнения операции требуется явное приведение типов.

Такой код будет работать:

int x = 0;
Single y = ((IConvertible)x).ToSingle(null);
А вот так нельзя разве?
int x = 0;
Single y = (Single)x;
или Single y = x as Single;
На сколько я помню, даже если не определен такой преобразователь, компилятор найдет подходящую цепочку, например сначла в Доубл а затем уже в Синг
Это другое. Если определена функция

public static operator Int32(Single value) {...}

То она вызовется, и ей наплевать, есть у объекта IConvertible или нет.

Если же есть функция

public static operator Int32(Double value) {...}

То, возможно, при попытке приведения пройдет и цепочка double -> float -> int.
4) В случае, если у нас определена функция

private static Int32 M(T t) where T: IComparable{...}

Вызов M(null) выдаст ошибку компиляции, так как компилятор не может вывести тип. Нужно использовать прямое указание M(null)
То есть M<IComparable>(null)

Парсер — лох.
Хм, действительно, но я вообще, имел в виду другое отличие :))
Я догадался, потому что это было бы слишком просто.

На самом деле, насколько я понимаю, задания ограничения с помощью where перекладывает часть проверок на CLR, в то время, как во втором случае проверка корректности целиком делается компилятором.

Это только мои догадки, сделанные на основании того, что вызов первого метода медленее, чем второго.
я уж не буду спрашивать, как вы время померяли, но хочу добавить, что верификация кода на уровне CLR все равно будет делаться.
Через Stopwatch и миллион вызовов, конечно же.
и много получилось?
я сдуру померял — одинаково в пределах погрешности.
Не сильно много, но в случае миллиона вызовов о какой погрешности может идти речь?
как раз о ней родной и идет речь. у меня например — второй быстрее
У меня тоже второй быстрее. Об этом и речь.
исходник — codepaste.ru/2121/
аутпут — codepaste.ru/2122/

матч окончился со счетом 2:2. понятно о какой погрешности идет речь?
Пробабли, я честно выполнил только один раз, получил разные результаты и успокоился.

Был неправ, исправлюсь.
1) Вопрос поставлен некорректно, так как парсер — лох и съел угловые скобочки. Определения типа System.Array из MSDN:

public abstract class Array: ICloneable, IList, ICollection, IEnumerable
А не реализует он эти интерфейсы только потому, что когда был создан System.Array, в C# еще не было никаких generics.
Как я понимаю, есть ещё одна причина :)
исправил, прошу прощения…
7) Если я все правильно помню, то к финализатору. (который ~ИмяКласса)
не знаю, к нему может быть тоже :)
Про финализатор я наврал, путем нехитрого подбора удалось применить к нему аттрибут Obfuscation
1) реализует, вопрос некорректный
2) не выполните, вопрос некорректный
3) А, если придираться к мелочам
4) проще ответить что у них общего. если не учитывать, что второе — хрень какая-то.
5) потому что метода ToSingle() — нету, потому и падает
6) ответили
7) нет такого в спецификации имхо

а минусы ставят за кривые вопросы
о, первый вопрос поменялся. но вы хоть приведите пример такого использования, а то-что то я не наблюдаю в Array всех богатств IList[T].
Я тоже не наблюдаю, но в .NET 3.5 есть extension под названием Array.OfType(), который преобразует массив в нужный нам тип.
объявим переменную
FileStream[] fsArray;

передадим её в метод
void Meth(ICollectionsCollection) {...}

Всё отработает…
FileStream [] реализует и IEnumerable, и IEnumerable, так что не пойдет.
Парсер — снова лох.

int[] arr = new int[10];
IEnumerable<int> a1 = arr;
IEnumerable a2 = arr;
Array a3 = arr;

Попробуйте сами.
не желаете ли выполнить (извиняюсь за кривую разметку)?

static void Meth(ICollection<long> collection)
{
Console.WriteLine(collection.GetType());
foreach (var i in collection.GetType().GetInterfaces())
Console.WriteLine(i);
}

заодно поясните причем здесь Array
1) Простите, это парсер съел…
2) Почему не выполнится?
3) Эти мелочи могут дорого стоить…
4) ммм… Почему хрень?
5) Как это нету, если интерфейс реализуется…
7) есть…
1) Простите, это парсер съел…
2) Почему не выполнится?
3) Эти мелочи могут дорого стоить…
4) ммм… Почему хрень?
5) Как это нету, если интерфейс реализуется…
7) есть…
Интерфейс может реализовываться явно или неявно.

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

В случае неявной реализации, функции интерфейса становятся заодно и публичными функциями объекта.

Пример явной реализации.

private IConvertible.ToSingle(IFormatProvider fp) {… }

Как видно, функция не является публичной, а значит доступа к ней нет. Однако, интерфейс реализуется, и в случае явного приведения объекта — мы получаем доступ к приватным функциям, которые определены таким образом.

Просто в большинстве случаев программисты на C# реализуют интерфейсы неявно, отсюда и вопросы.
Всё правильно :)
2) ну я вроде не новичок, но скомпилировать это мне не под силу
3) вот в конкретно этом случае — по барабану. если бы был какой-нить долгий arr.GetMyLength(), то был бы понятнее вопрос
4) вы очень быстро исправляете. серьезно — вопрос же общий. начиная от синтаксиса и до общения с переменной t внутри метода. а самим методы могут и одинаково работать. и снаружи даже и не заметишь
5) ну нету. а какой интерфейс его предлагает?
7) ну скажите пункт тогда
господа, вы в натуре оборзели со своими плюсометами. да пошли вы все в жопу вместе с хабром, сахарки
7. На анонимные методы и лямбды.
Короче, первый вопрос — непонятно, что имеется ввиду вообще, второй вопрос — не нашел, четвертый — они принципиально разные, одно дело — вызов метода, и другое — вызов генерика с констраинтом, что надо там найти — непонятно. Остальное ответил.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации