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

Reply via email to