Вот, думаю... Для удобства почти во всех классах пишу:

        public static implicit operator bool(AnyClass anyCalss)
        {
            return anyClass != null;
        }

чтобы проверку на null делать так:

if (anyClassInstance)
{
}

Нет ли тут подводных камней?

Здравствуйте, Eldar9x, Вы писали:

E>Нет ли тут подводных камней?
Why can't I use While(1) in C#?
c# truthy and falsy values

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

Здравствуйте, Eldar9x, Вы писали:

E>чтобы проверку на null делать так:

Зачем вообще "засахаривать" проверку на null?
В значительном числе случаев проверка на null предшествует выбросу ArgumentNullException.

Ну... по-моему, намного лаконичней смотрится. Не понимаю, почему нет неявного приведения базовых типов к bool в C#...
Все это как-то, громоздко что ли, смотрится:

if(obj != null)
{
}

Здравствуйте, Eldar9x, Вы писали:

E>Ну... по-моему, намного лаконичней смотрится. Не понимаю, почему нет неявного приведения базовых типов к bool в C#...
E>Все это как-то, громоздко что ли, смотрится:

E>

E>if(obj != null)
E>{
E>}
E>

Советую прочитать Невероятные приключения в коде. Можно на языке оригинала Fabulous Adventures In Coding.
А ключевой момент в фразе

по-моему, намного лаконичней смотрится

, которая не является техническим аргументом, приводящий к эффективной разработке (т.е. приносящей доход).

Здравствуйте, Eldar9x, Вы писали:

E>Вот, думаю... Для удобства почти во всех классах пишу:

Главный вопрос в том, для чьего "удобства" это делается: для удобства чтения или для удобства написания?
Очевидно, что у вас есть опыт разработки на языках С/С++, в которых использовалась именно эта запись для проверки на null. Если это так, то на первое время повысится как удобство чтения, так и удобство написания. Кстати, заимствование идиом из других языков является отличной идеей, но есть ли выигрыш в данном случае, ИМХО, не уверен.

Если же это только ради удобства написания, то такое удобство должно идти лесом перед удобством чтения. Мы, все же, тратим на чтение уже написанного кода на порядок больше времени, нежели на его написание. Так что оптимизировать нужно "понятность", которая, ИМО, в данном случае хуже, поскольку нужно лезть в код и думать, а как же именно устроено неявное преобразование к bool, ведь совсем не обязательно у этого преобразования только одна семантика.

Вот какие "за" и "против" мне приходят в голову по этому поводу:
Pros:
— код читабельней разработчикам С/С++
Cons:
— diversity. Если не все будут следовать этой идиоме в проекте, что вполне возможно, то такое разнообразие будет точно минусом и предыдущий единственный плюс пойдет лесом.
— код менее читабельный всем остальным ибо не идиоматичный для языка C#. Есть мнение, что неявные преобразования — это зло, поскольку нифига не понятно, что происходит за кулисами; это было справедливо даже в С++ и не менее справедливо в C#.
— захламление кода ненужными деталями. Это ж надо каждому своему классу такую штуку приколбасить; как-то не здорово это.
— diversity (да, знаю, что это уже было, но причина тут другая). Есть мысли как делать неявное преобразование к bool встроенных типов? Если нет, то для части классов у вас все еще будет if (someVal != null), а для другой: if(anotherVal). Мне было бы неприятно читать разный код в разных местах и думать, как мне проверять для этого конкретного случая;
— существует масса других способов решения этой же проблемы: всякие Code Contract и другие велики побольше и поменьше призванные бороться с проблемой, которую Тони Хоар назвал "своей ошибкой на миллиард долларов".

Так что, ИМХО, это того не стоит.

Здравствуйте, SergeyT., Вы писали:

ST>Здравствуйте, Eldar9x, Вы писали:

E>>Вот, думаю... Для удобства почти во всех классах пишу:

ST>Главный вопрос в том, для чьего "удобства" это делается: для удобства чтения или для удобства написания?
ST>Очевидно, что у вас есть опыт разработки на языках С/С++, в которых использовалась именно эта запись для проверки на null. Если это так, то на первое время повысится как удобство чтения, так и удобство написания. Кстати, заимствование идиом из других языков является отличной идеей, но есть ли выигрыш в данном случае, ИМХО, не уверен.

ST>Если же это только ради удобства написания, то такое удобство должно идти лесом перед удобством чтения. Мы, все же, тратим на чтение уже написанного кода на порядок больше времени, нежели на его написание. Так что оптимизировать нужно "понятность", которая, ИМО, в данном случае хуже, поскольку нужно лезть в код и думать, а как же именно устроено неявное преобразование к bool, ведь совсем не обязательно у этого преобразования только одна семантика.

ST>Вот какие "за" и "против" мне приходят в голову по этому поводу:
ST>Pros:
ST>- код читабельней разработчикам С/С++
ST>Cons:
ST>- diversity. Если не все будут следовать этой идиоме в проекте, что вполне возможно, то такое разнообразие будет точно минусом и предыдущий единственный плюс пойдет лесом.
ST>- код менее читабельный всем остальным ибо не идиоматичный для языка C#. Есть мнение, что неявные преобразования — это зло, поскольку нифига не понятно, что происходит за кулисами; это было справедливо даже в С++ и не менее справедливо в C#.
ST>- захламление кода ненужными деталями. Это ж надо каждому своему классу такую штуку приколбасить; как-то не здорово это.
ST>- diversity (да, знаю, что это уже было, но причина тут другая). Есть мысли как делать неявное преобразование к bool встроенных типов? Если нет, то для части классов у вас все еще будет if (someVal != null), а для другой: if(anotherVal). Мне было бы неприятно читать разный код в разных местах и думать, как мне проверять для этого конкретного случая;
ST>- существует масса других способов решения этой же проблемы: всякие Code Contract и другие велики побольше и поменьше призванные бороться с проблемой, которую Тони Хоар назвал "своей ошибкой на миллиард долларов".

ST>Так что, ИМХО, это того не стоит.

Именно! В том то и дело, что такой код легче читать. Ну, мне по крайней мере... Тогда как

obj != null

мозолит глаза .

Здравствуйте, MaLS, Вы писали:

MLS>Здравствуйте, Eldar9x, Вы писали:

E>>Ну... по-моему, намного лаконичней смотрится. Не понимаю, почему нет неявного приведения базовых типов к bool в C#...
E>>Все это как-то, громоздко что ли, смотрится:

E>>

E>>if(obj != null)
E>>{
E>>}
E>>

MLS>Советую прочитать Невероятные приключения в коде. Можно на языке оригинала Fabulous Adventures In Coding.
MLS>А ключевой момент в фразе
MLS>

MLS>по-моему, намного лаконичней смотрится

MLS>, которая не является техническим аргументом, приводящий к эффективной разработке (т.е. приносящей доход).

Кстати, пусть оффтоп, но все же... Наткнулся на очень интересную статью, объясняющую смысл volatile и потокобезопасности вообще:
здесь

В мире плюсов такое поведение не всегда возможно предугадать

Автор: slava_phirsov
Дата: 24.08.11

, именно из-за того, что это доступно из коробки; имхо лучше не вводить в заблуждение разработчиков, читающих ваш код.

Здравствуйте, Eldar9x, Вы писали:

ST>>Так что, ИМХО, это того не стоит.
E>Именно! В том то и дело, что такой код легче читать. Ну, мне по крайней мере... Тогда как

obj != null

мозолит глаза .

Кажется вы для себя уже все решили. Тогда зачем было спрашивать.

Здравствуйте, Eldar9x, Вы писали:

E>Вот, думаю... Для удобства почти во всех классах пишу:

Если уж засахаривать, то так:

    public static class ObjectExtensions
    {
        public static bool IsNull<T>(this T obj) where T : class
        {
            return null == obj;
        }

        public static bool IsNotNull<T>(this T obj) where T : class
        {
            return null != obj;
        }
    }

Заодно читаться будет легко, исчезнет возможность передать объект туда, где нужен bool, а также будет работать со встроенными типами (кроме Nullable<T>).

Здравствуйте, hardcase, Вы писали:

H>работать со встроенными типами (кроме Nullable<T>).

Хотя это решается аналогичным образом...

Здравствуйте, HowardLovekraft, Вы писали:



Как же люди код на C++ сопровождают?

Здравствуйте, Аноним, Вы писали:

А>Как же люди код на C++ сопровождают?

Не знаю кто как, но я в плюсовом коде стараюсь явно сравнивать с NULL.

Хотя в последнее время (после "знакомства" с VS2010) иногда стал юзать

template<class T>
inline bool is_null_ptr(T* const p)
{
 return p==reinterpret_cast<T*>(0);
}//is_null_ptr

Вот такие тараканы

Здравствуйте, hardcase, Вы писали:

H>Заодно читаться будет легко, исчезнет возможность передать объект туда, где нужен bool, а также будет работать со встроенными типами (кроме Nullable<T>).

Вы считаете, что

if (obj.IsNull())

чем-то лучше, чем

if (obj == null)

?



Кроме того, если не ошибаюсь, FDG рекомендует бросать ArgumentException из extension-методы, если он вызван у null-а.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, Аноним, Вы писали:

А>>Как же люди код на C++ сопровождают?

КД>Не знаю кто как, но я в плюсовом коде стараюсь явно сравнивать с NULL.

Я имел в виду, что когда я в незнакомом коде на C++ вижу ==, >> и т.п. я на самом деле не знаю, что он там делает. Ведь cout << 3 не сдвигает cout на три бита.

Так что (ptr == NULL) мжет значить все что угодно

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, hardcase, Вы писали:

L>Кроме того, если не ошибаюсь, FDG рекомендует бросать ArgumentException из extension-методы, если он вызван у null-а.

У нас есть целый набор extension-методов, которые, скажем так, null-safe -- им все равно, null на вход дали или нет. Очень помогает в жизни. Но они обычно имеют суффикс Safe, чтобы было понятно, что им на вход можно null передавать.

Вот, к примеру, очень полезный метод:

public static IEnumerable<TSource> AsEnumerableSafe<TSource>(this IEnumerable<TSource> source)
{
    return source ?? System.Linq.Enumerable.Empty<TSource>();
}

Здравствуйте, Eldar9x, Вы писали:

У меня давно сидит в голове одна мысль, связанная с тем, что причина некоторых "тормозов" .Net связана не только с GC и JIT, но и с подобными проверками в всех возможных местах стандартной библиотеки.
Вот в C++ это бы проверяли (если бы вообще проверяли) в отладочной версии СRT (ну или MFC), а в Release все эти ASSERT просто бы исчезли.
Ну вот, например, нафига WPF уже в отлаженной и без ошибок работающей программе постоянно проверяет "а мы вызваны из того же потока, из которого созданы?".
Я понимаю, что проверка аргумента функции на null и выдача ArgumentNullException более информативна для определения причины ошибки, чем NullReferenceException (которая может значить что угодно), но в отлаженной программе, переданной заказчику ошибок ArgumentNullException быть не должно. В общем, я хочу Release-версию .Net

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, hardcase, Вы писали:

H>>Заодно читаться будет легко, исчезнет возможность передать объект туда, где нужен bool, а также будет работать со встроенными типами (кроме Nullable<T>).

L>Вы считаете, что
L>

L>if (obj.IsNull())
L>

L>чем-то лучше, чем
L>

L>if (obj == null)
L>

L>?

L>

Я считаю что это лучше чем оператор неявного преобразования в bool. Автор говорил про читабельность — в моем варианте она на высоте.
А в целом вот эти два варианта одна фигня.

L>Кроме того, если не ошибаюсь, FDG рекомендует бросать ArgumentException из extension-методы, если он вызван у null-а.

Какой FDG в контексте этого топика? Хотя пускай лучше авторы FDG подумают как сделать non-null ссылочные типы, а не обходить грабли которые сами же и положили...

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, Eldar9x, Вы писали:

ST>>>Так что, ИМХО, это того не стоит.
E>>Именно! В том то и дело, что такой код легче читать. Ну, мне по крайней мере... Тогда как

obj != null

мозолит глаза .

Doc>Кажется вы для себя уже все решили. Тогда зачем было спрашивать.

Ну, почему же? В С# я совсем не спец, поэтому и интересуюсь. К примеру, с private protected полями меня здесь убедили, что лучше делать их только private, и далее я так буду писать. Также и с этим вопросом получается не все так однозначно.