Имеет ли смысл использовать as вместо приведения, даже если нет нулевой проверки?

Ваше понимание верно. Для меня это звучит как попытка микрооптимизации. Если вы уверены в типе, вам следует использовать обычное приведение. Помимо создания более разумного исключения, он также быстро дает сбой. Если вы ошибаетесь в своем предположении о типе, ваша программа немедленно выйдет из строя, и вы сможете сразу увидеть причину сбоя, а не ждать NullReferenceException, ArgumentNullException или даже логической ошибки в будущем. В общем, выражение as, за которым не следует null проверка, является запахом кода.

С другой стороны, если вы не уверены в приведении и ожидаете, что оно завершится ошибкой, вам следует использовать as вместо обычного приведения, заключенного в блок try-catch. Более того, рекомендуется использовать as вместо проверки типа с последующим приведением. Вместо:

if (x is SomeType)
   ((SomeType)x).SomeMethod();

который генерирует isinst инструкцию для is ключевое слово и castclass инструкция для приведения (эффективное выполнение приведения дважды) вы должны использовать:

var v = x as SomeType;
if (v != null)
    v.SomeMethod();

Это только генерирует isinst инструкцию. Первый метод имеет потенциальный недостаток в многопоточных приложениях, поскольку состояние гонки может привести к тому, что переменная изменит свой тип после успешной is проверки и завершится ошибкой на линии приведения. Последний метод не подвержен этой ошибке.

_{Следующее решение не рекомендуется для использования в производственном коде. Если вы действительно ненавидите такую ​​фундаментальную конструкцию в C #, вы можете подумать о переходе на VB или другой язык.}

Если кто-то отчаянно ненавидит синтаксис приведения, он / она может написать метод расширения, имитирующий приведение:

public static T To<T>(this object o) { // Name it as you like: As, Cast, To, ...
    return (T)o;
}

и используйте аккуратный [?] синтаксис:

obj.To<SomeType>().SomeMethod()

ИМХО, as просто имеет смысл в сочетании с null проверкой:

var y = x as T;
if (y != null)
    y.SomeMethod();

Использование as не применяет определенные пользователем преобразования, в то время как приведение будет использовать их там, где это необходимо. В некоторых случаях это может быть важным отличием.

Я немного об этом писал здесь:

http://blogs.msdn.com/ericlippert/archive/2009/10/08/what-s-the-difference-between-as-and-cast-operators.aspx

Я понимаю вашу точку зрения. И я согласен с его сутью: оператор приведения сообщает: «Я уверен, что этот объект можно преобразовать в этот тип, и я готов рискнуть получить исключение, если я ошибаюсь», тогда как оператор «as» сообщает «Я не уверен, что этот объект можно преобразовать в этот тип; дайте мне ноль, если я ошибаюсь».

Однако есть небольшая разница. (x as T) .Whatever () сообщает: «Я знаю не только то, что x можно преобразовать в T, но, более того, это включает только преобразования ссылок или распаковки, и, кроме того, что x не является нулевым». Это передает иную информацию, чем ((T) x) .Whatever (), и, возможно, это то, что задумал автор кода.

Я часто видел ссылки на эту вводящую в заблуждение статью как доказательство того, что «как» есть быстрее, чем литье.

Одним из наиболее очевидных вводящих в заблуждение аспектов этой статьи является изображение, которое не указывает на то, что измеряется: я подозреваю, что он измеряет неудачные приведения (где "as", очевидно, намного быстрее, так как исключение не генерируется ).

Если вы потратите время на измерения, то увидите, что приведение, как и следовало ожидать, быстрее, чем "as", когда приведение выполнено успешно.

Я подозреваю, что это может быть одной из причин того, что «культ карго» использует ключевое слово as вместо приведения.

Прямое приведение требует пары скобок больше, чем ключевое слово as. Так что даже в том случае, если вы на 100% уверены, что это за тип, это уменьшает визуальный беспорядок.

Однако согласился с исключением. Но, по крайней мере, для меня, большинство случаев использования as сводится к последующей проверке null, что мне кажется более приятным, чем перехват исключения.

99% случаев, когда я использую «как», - это когда я не уверен, какой на самом деле тип объекта.

var x = obj as T;
if(x != null){
 //x was type T!
}

и я не хочу ни перехватывать явные исключения приведения, ни делать приведение дважды, используя "is":

//I don't like this
if(obj is T){
  var x = (T)obj; 
}

Просто потому, что людям нравится, как это выглядит, очень читабельно.

Посмотрим правде в глаза: оператор приведения / преобразования в C-подобных языках довольно ужасен с точки зрения удобочитаемости. Я бы хотел, чтобы в C # был принят синтаксис Javascript:

object o = 1;
int i = int(o);

Или определите оператор to, эквивалент as при приведении:

object o = 1;
int i = o to int;

Людям нравитсяas так сильно, потому что это позволяет им чувствовать себя в безопасности от исключений ... Как гарантия на коробку. Парень дает на коробку причудливую гарантию, потому что он хочет, чтобы внутри вас было тепло и жарко. Вы полагаете, что кладете эту коробочку себе под подушку на ночь, Фея Гарантии может прийти и оставить четвертак, я прав, Тед?

Вернемся к теме ... при использовании прямого приведения существует вероятность недопустимого исключения приведения типов. Таким образом, люди применяют as как универсальное решение для всех своих задач по кастингу, потому что as (сам по себе) никогда не вызовет исключения. Но самое забавное в том, что в приведенном вами примере (x as T).SomeMethod(); вы обмениваете исключение недопустимого приведения для исключения нулевой ссылки. Что скрывает реальную проблему, когда вы видите исключение.

Я обычно не использую as слишком много. Я предпочитаю тест is, потому что он кажется мне более читаемым и имеет больше смысла, чем попытка приведения и проверка на null.

Это должно быть одно из моих главных раздражителей < / а>.

В D&E Страуструпа и / или в каком-то сообщении в блоге, которое я не могу найти прямо сейчас, обсуждается понятие оператора to, который отвечал бы на вопрос, сделанный https://stackoverflow.com/users/73070/johannes-rossel (т. е. тот же синтаксис, что и as, но с DirectCast семантикой).

Причина, по которой это не было реализовано, заключается в том, что приведение типов должно вызывать боль и быть уродливым, поэтому вас отталкивают от его использования.

Жалко, что «умные» программисты (часто авторы книг (Джувал Лоуи IIRC)) обходят это стороной, злоупотребляя таким образом as (C ++ не предлагает as, вероятно, по этой причине).

Даже у VB больше согласованности в единообразном синтаксисе, который заставляет вас выбирать TryCast или DirectCast и принимать решение!

Я считаю, что ключевое слово as можно рассматривать как более элегантную версию dynamic_cast из C ++.

Вероятно, он более популярен без каких-либо технических причин, а просто потому, что его легче читать и он более интуитивно понятен. (Я не говорю, что от этого лучше, просто пытаясь ответить на вопрос)

Одна из причин использования «как»:

T t = obj as T;
 //some other thread changes obj to another type...
if (t != null) action(t); //still works

Вместо (плохой код):

if (obj is T)
{
     //bang, some other thread changes obj to another type...
     action((T)obj); //InvalidCastException
}