About return status test

[wij]

Hi:
I have a class for return status, it contains a pointer member.
Now, I'd like to add two members operator const void*() and
bool operator!() like the case in std::basic_ios, to ease the test.

class Ret {
RetInfo* _p;
public:
Ret(int error_no);
operator const void*() const;
bool operator!() const;
}

So applications can say:
extern Ret f();

if(f()) {.....}
if(!(r=f())) {.....}

Because the purpose is mostly to shorten condition test statements.
Is there any known unwanted side effect or how good it is in practice?

 

[Alf P. Steinbach /Usenet]

* (e-mail address removed), on 14.08.2010 04:56:

Hi:
I have a class for return status, it contains a pointer member.
Now, I'd like to add two members operator const void*() and
bool operator!() like the case in std::basic_ios, to ease the test.

class Ret {
RetInfo* _p;
public:
Ret(int error_no);
operator const void*() const;
bool operator!() const;
}

So applications can say:
extern Ret f();

if(f()) {.....}
if(!(r=f())) {.....}

Because the purpose is mostly to shorten condition test statements.
Is there any known unwanted side effect or how good it is in practice?

A Ret object will be implicitly convertible to void*.

This can cause problems with resolution of a call of an overloaded function,
e.g. for operator<<.

Some people think that the thing to do to avoid that is to make the pointer type
a very private one. I say that the thing to do is to make the testing explicit,
not implicit. Explicit is good, implicit is bad (except where implicit is good,
of course, but keep in mind that source code is not about communicating to the
compiler, it is about communicating to readers of the source code, and implicit
reduces it all to unreliable vague hinting).

So, add a member function that says what this bool value is about, e.g.,
'succeeded'.

Then the client code can say 'if( f().succeeded() )'.


Cheers & hth.,

- Alf