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  

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  

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  
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.


Gimp-developer mailing list

Reply via email to