Hi Frederik,
my main attend was to mention the problem of pointers, regarding
uninitialized values. That's why I insisted on Null, and it makes
sense often to use 0 or 0.0 for other values.
As "strings" are char*, NULL should be used, not "".
You are right, that in some seldom situations it might make sense
to initialize values to other start values. But they should always be
predictable.
If for example 0 is part of the used range of values and you have -1
not in that range, -1 might make sense.
For example filedescriptor-stuff in Unix-system-near applications
might start with fd = -1 and if something goes wrong or you
acidently removed your initializing funtion, the -1 will show you a
problem.
Other values for example might be: INT_MAX or INT_MIN.
What is the special on all those values?
The special thing is, that they are EXCEPTIONS to what is normal.
Other languages have exceptions built in, and you can catch them.
The same is here: a NULL-pointer is an exception. And it's the only
exception that you have for your pointers, that is working all the
time.If you may have a set of function pointers, which only can be
valid, you also can test against them. But even in that case, NULL
would be an exception too.
For int values enums are often a good idea, or language / system constants.
So, all in all: the most interesting values for initilazisation at definition
are those values, that should never occur.
Only against them you can test. glib provide those tests for incoming
parameters; but if the caller has forgotten initialization, your test
gives
you wrong feeling of security. And if you in your function miss the
init to real values, at least the EXCEPTIONAL init, right at the
beginning of your function will the called functions - if thex test
their arguments - fail.
So, to set the tests into a working mode, you must provide it values,
that it can detect.
So much for now.
Ciao,
Oliver
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
