Comments 17
А это что за синтаксис вообще <>? (int num = <> 1__state;)
промежуточный объектный код сгенерированный компилятором. В каком-то смысле, можно сказать что это ассемблер#.
Этот язык называется IL. Он много шире по возможностям чем C#. Например, на нем можно вполне себе реализовать перегрузку методов по возвращаемому значение.
Это часть имени поля (<>1__state).
То, что вы видите, это не IL/промежуточный код, как утверждают комментаторы выше, а C#, сгенерированный из IL. Угловые скобочки в именах идентификаторов в C# невалидны, а в IL - вполне себе норм.
Зачем эти скобочки нужны? Просто позволяют отличить пользовательский код от кода, сгенерированного компилятором.
Добрый день, перевод очень некачественный, очень сложно читать текст курсивом, с нижним подчеркиванием, без разделения на абзацы, язык очень кастрирован, поход на перевод bing, потому что даже google или yandex, не говоря о chat gpt, или даже специализированных технических AI, переводят его по смыслу не по словам а по токенам, с учетом грамматической модели языка и трансляции. Тот перевод, что я увидел, ну, честно сказать, откровенная халтура. Очевидно, что совершенно бесполезные, огромные куски текста сохранили форму и порядок следования глаголов принятых в английском языке, то есть все эти куски, по-сути не написаны на русском языке. Ребята, я все понял из статьи, но это не работа. Это сдача материала очевидно заказной статьи на о...сб. Я понимаю, что 4к знаков сдать надо, но совесть имейте, вы специально курсивом сп подчеркиванием показали, что вам совершенно не интересно сделать качественный пусть даже машинный, перевод... Ну, как то так. Грустно
что вам совершенно не интересно сделать качественный пусть даже машинный, перевод
если бы вы привели хоть один конкретный пример фразы или абзац который вас особенно огорчает, с пояснениями что же конкретно вам там не нравится, это была бы конструктивная критика, и я бы был вам очень за нее благодарен.
Способ выделения с подчеркиванием действительно не самый лучший, но другого к сожалению я не вижу. Мне надо как-то различать то, что я от себя пишу и то, что цитирую, хоть и в своей интерпретации. Потом, я же дал ссылку на другой перевод, вроде как мой не обязательно читать.
Обратите внимание, автор Поста напоминает нам про использование интерфейсов (a pattern of APIs) как необходимое условие использования, по крайней мере таких ключевых слов из C# как: await, foreach, я могу еще вспомнить using, например, все они требуют, чтобы помеченное выражение приводилось к типу с определенным интерфейсом.
Нету тут приведения типов, если конечно имеется ввиду type casting. В этом-то и суть.
Про using это он зря. Там как-раз типизация строгая. Ему нужен IDisposable, а не какой-попало тип с методом Dispose().
То, что Автор Поста называет pattern of APIs также известно как утиная типизация. Если бы переводчик использовал этот общепринятый термин, все эти объяснения были бы излишни.
То, что Автор Поста называет pattern of APIs также известно как утиная типизация.
насколько я знаю foreach проверяет наличие у объекта list в выражении:
foreach (var obj in list)
наличие интерфейсов enumerable . Там, по моему, есть три варианта интерфейсов которые поддерживает foreach , наличие проверяется по очереди, то есть компилятор не делает никаких предположений типа того, что "оно плавает как утка, или перечисляется как утки", компилятор проверяет факт наличия или отсутствия интерфейса у объекта, причем на этапе компиляции. То есть если внутри объекта будет список, но интервейс к нему не выставлен наружу, будет ошибка, компилятор не будет исходить из того что его все таки можно по-перечислять.
Я, честно говоря, очень сомневаюсь, что это можно назвать примером утиной типизации.
Насколько помню для foreach требуется наличие определённых названий методов, а не явный интерфейс
Попробуйте вот это:
class MyEnumerator
{
int i;
public object Current => i;
public void Reset () {i=0;}
public bool MoveNext()
{
return ++i <= 5;
}
}
class MyEnumerable
{
public MyEnumerator GetEnumerator() => new MyEnumerator();
}
void Main()
{
var en = new MyEnumerable();
foreach(int n in en)
{
Console.WriteLine(n);
}
}
Я пробую в LinqPad, поэтому тут нет юзингов и класса, в котором находится Main(). Но я уверен, что и в Студии MyEnumerable будет работать
видимо вы вот это
A type has the public parameterless
GetEnumeratormethod. TheGetEnumeratormethod can be a type's extension method.
имеете ввиду. Да, достаточно наличия метода с определенной сигнатурой (все таки parameterless , а не просто с именем), но я все равно не уверен что этого достаточно чтобы называть это утиной типизацией, мне кажется для утиной типизации рассматривается что-то на этапе run-time-а, а здесь все на этапе компиляции. Но я совсем не специалист по утиной типизации, конечно.
Прошел я по ссылке на AwaitUnsafeOnCompleted(), и мое внимание привлекла строчка:
Contract.Assert(!Object.ReferenceEquals((object)stateMachine, (object)stateMachine), "Expected an unboxed state machine reference");В статье описаны титанические усилия разрабов по экономии на боксинге, а тут он выполняется целых два раза только чтобы проверить, что TStateMachine является value-типом.
Во-первых, такие вещи незачем проверять в рантайме. Вместо этого можно было в определение функции, вот в это место:
where TStateMachine : IAsyncStateMachine
Добавить слово struct, вот так:
where TStateMachine : struct, IAsyncStateMachine
Допустим, что менять сигнатуру метода уже поздно, потому что уже много где используется. Тогда рантайм-проверка нужна, но ее можно написать так:
Contract.Assert(typeof(TStateMachine).IsValueType);И, наконец, если проверка такая дорогая, а вы так заботитесь о быстродействии, ее можно было бы и просто убрать.
Добавить слово struct, вот так:
where TStateMachine : struct, IAsyncStateMachine
вообще то в статье процитировано (фактически):
в отладочных сборках компилятор C# фактически генерирует эти типы стейт-машин как классы, поскольку это может помочь в определенных случаях при отладке
то есть TStateMachine это не всегда структура, иногда это сразу класс.
вообще конечно странный ассерт, если учесть тот факт что ассерты в релизе не подлежат компиляции, обычно. А в дебаге вроде как автор Поста обещает нам класс вместо структуры. Может этот ассерт конфигурируется чтобы работать в каком-то специальном билде для отладки релиза? Они там иногда очень хитрые штуки изобретают, они могут!
Как на самом деле Async/Await работают в C#. Часть 6. Анализ результатов компиляции асинхронных вызовов