In my code in cases like this I return NIL instead of NULL
pointer. This
is better for future compatibility, if we are going to change to
collectible pointers in the future. Since the value of the
collectible
pointer will not be NULL.
My vote goes to returning same type for both error and success
cases. Anyhow "Empty( retval )" is working for both cases, so it
seems the "best practice" when validating such return values.
We can not return empty collectible pointer! So, simple NULL pointer
instead of collectible is also a kind of different type. Well, both
has VALTYPE() == "P", but in C code it looks like different type:
You're right, but in this case I used to return hb_retptr( NULL ), which
is also "P" type, but non-collectible. Hard to tell which is better.
Problem creep in probably as soon as we start to have collectible
*typed* pointers, because in this case we may not be able to keep the
type while returning NULL, but the same is the problem with NIL,
maybe NIL is slightly cleaner here, as it doesn't suggest anything
more than just being empty.
HB_FUNC( AAA )
{
if( somefunc() == OK )
hb_retptrGC( ... );
else
hb_retptr( NULL );
}
HB_FUNC( BBB )
{
some* pPtr = hb_parptrGC( ..., 1 );
// If AAA returned NULL, here we do not have a valid GC pointer
// just like invalid type was passed...
if( pPtr )
....
else
hb_errRT_BASE_SubstR( EG_ARG, 3012, NULL, HB_ERR_FUNCNAME,
HB_ERR_ARGS_BASEPARAMS );
}
All above does not mean we need NIL instead of NULL pointer, but
difference is minor. Sometimes it is even better to have NIL, for
example: printed error log is more clear if you see NIL as parameter
instead of <POINTER> parameter, if we do not see pointer value
explicitly.
Yes.
One of the reason why I am writing this letter without having the
strong opinion NIL vs. NULL is future extension of pointers. Przemek
has some ideas about extending pointers to support methods. Maybe
EMPTY() should be a kind of overloadable method/operator and every
class (including pointers) can have EMPTY() overloaded. This gives
possibility to test EMPTY() for varios classes/pointer. In this case
we can use return value of exactly same type. So, one more vote
"EMPTY()".
Summary: I would be nice, if we can see (or think about) a future
extensions to decide some "no important" things like NIL vs. NULL
today.
I agree. No strong opinion here on either side yet, so far I used to
use NULL in practice.
So far conclusion is that callers should use Empty().
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour