2013-07-29 3 views
5

У меня есть следующее, если условие param.days - это строка.Почему это не разрешено в C#?

if (param.days != null) 

Это прекрасно работает, но если я скажу

If (param.days) 

то не правильно оценить во время выполнения. Оба оператора не совпадают с C#.
Он говорит, что значение равно null, но затем C# пытается передать его в bool, который не является нулевым. Почему дизайнеры C# решили сделать это таким образом? Такое утверждение действительно в C++, но почему это не считается допустимым в C#?

+11

null не является логическим – Sayse

+4

Каков тип 'param.days'? –

+0

@Sayse: Да, я понимаю, но есть ли другая причина для того, чтобы это не оценивалось правильно. Или это из-за того, что bool - это тип, который не является нулевым, и поэтому другого выхода нет. – ckv

ответ

18

Такое утверждение справедливо в C++, но почему это не считается действительным в C#

Поскольку C# принимает различные правила Languange. Он не предполагает, что каждое число/ссылку можно рассматривать как логическое значение, проверяя, равен ли он нулю vs ненулевой, null vs non-null. Если вы хотите проверить, имеет ли значение null: проверить, является ли оно нулевым.

Примечание: если days фактически T? (ака Nullable<T>), то вы можете проверить:

if(param.days.HasValue) 

, который затем идентичен if(param.days != null)

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

1

В C# оператор If требует, чтобы содержимое брекеров было логическим выражением.

Рассмотрите If ("Hello World").

Действительно ли «Hello World» является истинным или ложным? Это не так, это строка.

Возможно, вы захотите рассмотреть выражение LINQ, такое как .Any(), например, If (myListOfCats.Any()), поскольку ваше .days свойство подразумевает коллекцию объектов.

+2

Это ужасный пример, так как 'if (« Hello World ») будет компилироваться в C++. Вопрос задает вопрос о различии между C++ и C#, поэтому на самом деле это не отвечает. – Dukeling

+3

Это не 'C++', это 'C#' – NibblyPig

+0

@Dukeling. Вы можете утверждать, что вопрос на самом деле спрашивает, почему C# не поддерживает синтаксис, который возможен на C++, не обязательно различия между ними. –

1

Сравнение в выражении if должно оцениваться с помощью логического результата. param.days не является логическим. Вам нужно сравнить значение с нулевым, чтобы получить логический результат. C# безопасен по типу.

6

C#, в отличие от C++, не подразумевает, чтобы целое целое приводило к bool.

1

Сравнение в инструкции if требует результата boolean. param.days является string не boolean. C# не подразумевает листинг integer - bool.

Вам нужно сравнить значение обнулить или использовать string.IsNullOrEmpty(), чтобы получить boolean результат Если вы хотите сделать так, попробуйте этот код:

if (!string.IsNullOrEmpty(param.days)) 
{ 
} 

ИЛИ

if (param.days!=NULL) 
{ 
} 
5

Для уточнения, это отвечает на вопрос о поправке в комментариях: почему дизайнеры C# решили не применять null для логической оценки, тогда как C++ допускает это.

Взято из поста Эрика Липперта «null is not false»:

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

И аналогично для типов с нулевым значением; в некоторых языках значение null неявно рассматривается как «ложное».

Дизайнеры C# считали эти функции и отклоняли их. Во-первых, потому что обработка ссылок или типов значений с нулевыми значениями как булевых является запутанной идиомой и потенциально богатым источником ошибок. И, во-вторых, , потому что семантически кажется самонадеянным автоматически переводить null - что должно означать «это значение отсутствует» или «это значение равно неизвестно» - для «это значение логически ложно».

Это конкретное предложение охватывает ваш пример string, но ничего из других типов не имеет неявной булевой оценки.

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

Смежные вопросы