Testing for nullptr for a ref object

[Edward Diener]

For a ref object x, can I say "if (x)" rather than "if (x != nullptr)"
to test that x is pointing to something ?

[Bruno van Dooren]

> For a ref object x, can I say "if (x)" rather than "if (x != nullptr)" to

test that x is pointing to something ?

Yes, you can.
a quick test would have given you the answer immediatly.

Note that this check does not indicate if you already disposed(deleted) x or
not.
delete x;
if(x)
{
//will be true after the delete
}

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[Holger Grund]

"Bruno van Dooren" <br**********************@hotmail.com> wrote

For a ref object x, can I say "if (x)" rather than "if (x != nullptr)" to
test that x is pointing to something ?

Yes, you can.
a quick test would have given you the answer immediatly.

Do you say the answer is trivial? If so I must admit I disagree, but then
I'm must admit I haven't read much of the C++/CLI standard.

Anyway, my interpretation is that the compiler will consider a conversion
from x to bool better than the check against nullptr.

So if a conversion from x to bool exists it will be chosen over the
!= nullptr check (BTW: there is no standard conversion from
handle-to-bool as there is for native pointers).

And indeed this is what VC++ does. The program below prints

x
!y

for me.

using System::Console;
ref class X {};
ref struct Y { operator bool() { return false; } };
int main()
{
X^ x = gcnew X;
Y^ y = gcnew Y;
if (x) Console::WriteLine("x"); else Console::WriteLine("!x");
if (y) Console::WriteLine("y"); else Console::WriteLine("!y");
}

-hg

[Bruno van Dooren]

>>> For a ref object x, can I say "if (x)" rather than "if (x != nullptr)"

to test that x is pointing to something ?

Yes, you can.
a quick test would have given you the answer immediatly.

Do you say the answer is trivial? If so I must admit I disagree, but then
I'm must admit I haven't read much of the C++/CLI standard.

Anyway, my interpretation is that the compiler will consider a conversion
from x to bool better than the check against nullptr.

So if a conversion from x to bool exists it will be chosen over the
!= nullptr check (BTW: there is no standard conversion from
handle-to-bool as there is for native pointers).

Hi Holger,
Your example also works with native C++. if you create a handle class that
has a bool conversion, you can
do something like

if(myHandle)
{
}
to check if the handle in your object is valid or not.

there was a discussion about this topic 1 or 2 weeks ago.
my preference is to only use 'if' with real bools that are either return
values or the result of an equation.

my point was that if you want to know for sure, just do a quick test.

of course it could be dangerous to rely on the automatic handle to bool
conversion
because if soemone adds a conversion to bool later in the development
traject, your code suddenly starts doing funny things.
I admit I didn't think of the case where there was a conversion to bool.

Thanks for correcting me.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[Holger Grund]

Hi Bruno,

"Bruno van Dooren" <br**********************@hotmail.com> wrote

Your example also works with native C++. if you create a handle class that
has a bool conversion, you can
do something like

if(myHandle)
{
}
to check if the handle in your object is valid or not.
I'm afraid I don't quite understand. What do you mean with "native c++"
and "handle class"? Obviously, standard C++ doesn't have handles.
The language designers often claim that handles are very similar to
pointers.

If you used the example with native classes (i.e.struct/class instead
of ref struct/ref class) and pointers instead of handles (explicitly
initialized oc.),
you'd get different results, because the compiler doesn't consider
user-defined
operators on pointer types (and even if C++ allowed that the
pointer-to-bool
conversion is a standard conversion and therefore would have a better
conversion rank anyway).
of course it could be dangerous to rely on the automatic handle to bool
conversion
because if soemone adds a conversion to bool later in the development
traject, your code suddenly starts doing funny things.
I admit I didn't think of the case where there was a conversion to bool.

I was more thinking of the lines of function or class template which works
for most template arguments, just not for the one you didn't test it with
....

But then, at least for C++ developers it should be clear that an implicit
conversion is rarely a good idea (especially since, bool-to-int-promotion
is a standard conversion, too and therefore a UDC to bool followed
by integral promotion to int is a valid conversion sequence.

-hg

[Bruno van Dooren]

>> Your example also works with native C++. if you create a handle class

that has a bool conversion, you can
do something like

if(myHandle)
{
}
to check if the handle in your object is valid or not.

I'm afraid I don't quite understand. What do you mean with "native c++"
and "handle class"? Obviously, standard C++ doesn't have handles.
The language designers often claim that handles are very similar to
pointers.

Hi Holger,

I think was not clear enough about the meaning of 'handle' in the context of
my example.
Someone had a question about a self developed class that he used for
wrapping a file handle. (hence the term 'handle class').
His question was if and how he could enable his class to be used like this:

if(myHandle)
{

}

to represent the fact that myHandle contained a valid file handle or not.
providing a conversion to bool solves this problem.
this will of course only work for instances. not pointers. that is why I
suggested providing an explicit IsValid method for his class.

in the case of the op, suppose you have a ref class on which you use if(x)
to check for a nullptr.
if someone adds a conversion to bool sometime after you have programmed your
part, your code will suddenly start behaving erroneously.

I agree with you that relying on implicit conversion is not a good idea
because it makes code harder to read and maintain.
especially if you didn't write it yourself.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"