2

Sorry if my question seem stupid.

In C++, this code work:

Foo* foo = new Foo();
if (foo)
    ....;
else
    ....;

In C#, this doesn't work:

Object obj = new Object();
if (obj)
    ....;
else
    ....;

because Object class cannot be implicitly convert to bool (obvious, no problem about that), and it doesn't implement true operator.

So my question is why doesn't Object implement the true operator (just check whether itself is null or not, sound easy enough)? Is it just because of code readability or something?

Tr1et
  • 873
  • 11
  • 25
  • I think it's more of the case in c/c++ that it is testing for _whether `obj` is not null_ irrespective of whether it is an object or not, rather than _calling some magic true operator_. e.g. `if (somePointerToCharArray)` equally passes the guard operator in c/c++ code –  Nov 01 '16 at 04:26
  • C++ does not have boolean data type. `if` just check if an integer value is zero or not. – Niyoko Nov 01 '16 at 04:29
  • @NiyokoYuliawan _"C++ does not have boolean data type"_ - Incorrect. http://stackoverflow.com/a/356728/585968 –  Nov 01 '16 at 04:39
  • @MickyD Yes, sorry, I mistakenly it with C. – Niyoko Nov 01 '16 at 04:41

3 Answers3

6

It's because of code clarity. A lot of design choices for C# were made with the goal that the code should be written in such a way that it is immediately obvious what it is trying to do. If you have something like:

Object obj = ...;
if (obj)
     ....

What does if(obj) mean? Is it checking if obj true? Is it checking if it is null? Is it checking if it is 0? It's not clear to someone glancing at the code and necessitates the programmer to consult the C# documentation to see what this particular syntax is doing. So instead, C# has you say

Object obj = ...;
if (obj == null)
    ....

This way, it is obvious what you are trying to do.

This is the same reason why C# requires you to instantiate your local variables as well as declare them before you can use them in code. The value of an uninstantiated variable is ambiguous and depends on the compiler's configuration, so instead of forcing you to do research or perform guesswork, C# instead makes it so you have to code in such a way that your intention is clear.

Abion47
  • 22,211
  • 4
  • 65
  • 88
  • So the true operator is useless in C#? – Tr1et Nov 01 '16 at 05:41
  • @Tr1et The `true` keyword is a boolean literal, just like `5` is an integer literal and `"Hello World"` is a string literal. And just like other literals, it's for when you want to instantiate, modify, or compare boolean values. – Abion47 Nov 01 '16 at 06:08
  • 1
    @Abion47: He's asking about the true operator, not the true keyword. – Brian Nov 02 '16 at 15:17
  • 1
    @Tr1et: No, you can implement the true operator to your own classes, thus allowing you `if(myInst)`. [This Question](http://stackoverflow.com/q/33265/18192) has a simple example, as well as a discussion of the far less useful `false` operator (which is required if the true operator is implemented). – Brian Nov 02 '16 at 15:20
  • @Brian I deleted my previous comment about that keyword because it was part of a conversation that the other guy deleted all of his side. But the gist of it is that I would never encourage anyone to override the `true` keyword because it is one of those things that has legitimate uses but is abused far too often and promotes bad coding practice. Overriding the `true` keyword on any old object hides the operation it is performing and subverts the code clarity I talked about in this answer. – Abion47 Nov 02 '16 at 17:38
5

The fundamental answer to your question is the one given in the accepted answer: because C# was designed to avoid, not perpetuate the design errors of C.

But more specifically: you ask why a type does not implement operator true. The answer to that question is: the purpose of operator true is to implement the short circuiting && and || operators. Since there is no desire to have object implement either & or && or | or ||, there is no reason to implement operator true or operator false.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
1

Boxing.

It would really be horribly confusing for conditionals involving booleans to do the exact opposite when the value is boxed.

What do you want from:

object o = false; // Yes, this is legal, it makes a boxed System.Boolean
if (o) { ... }

For this reason it's fine for bool-like types to be tested in conditions, but not for System.Object which is the base class for all boxed values.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720