Am Freitag, 23. April 2010 08:39:52 schrieb Oliver Bandel: > Zitat von "Sven Neumann" <sven@xxxxxxxx>: > > Hi, > > > > On Thu, 2010-04-22 at 14:38 +0200, Fredrik Alströmer wrote: > >> For the record, I'm not necessarily against setting a predefined value > >> to variables sometimes. I'm just against doing it for the wrong > >> reasons, and I'd much rather have the compiler say "Warning: might be > >> used uninitialized in this context" as a part of the static analysis, > >> rather than chase down the bug where a value is 0 at run time > >> (remember, I'm primarily talking corner cases here). > > > > Totally agreed. I also prefer the compiler telling me that a refactoring > > I've just done is not correct because I forgot to initialize a variable > > in a code path. This has happened to me and the compiler warning caught > > some potential bugs. If we would always initialize all variables this > > mistake would have gone unnoticed. > > [...] > > If this case would be undetected by the compiler, but you have > initialized it to your EXCEPTIONAL value at the same line, at which > the variable is defined, > then - when running the code, it would have shown you your problem. You are comparing a bug turning up when actually running the code vs. turning up when compiling it. I prefer to find and fix it *before* the code gets executed. Whenever a compiler is able to tell about a possible bug development is quickened. Which is one of the reasons some languages have explicitly been designed to allow for good static code evaluation. > Will the compiler stop execution on any warning? It should, and not > compile any code that gives warnings, otherwise your attempt will not > work. People will ignore it "just for testing". And that's the > beginning of the problems ;-) You can always tell the compiler to regard warnings as bugs and stop compilation. On the other hand, the compiler should go on and try to compile the rest. That way, more bugs can be found and eliminated in a single turn-around cycle. Which again means improved productivity. Ignoring warnings "just for testing" is bad style and contra-productive. Any serious programmer doing that should be slapped with a wet trout. > The other case is: values change during the meantime. > If you reset them to the exceptional values after usage, > especially I mean pointers here, that's a good idea. Agreed with that. But then again, optimally these pointers themselves should not exist any more (which means you can't dereference them). What you seem to be talking about here is the use of global variables that get re-used over and over. Resetting those to sane values is absolutely a must, but one should avoid the use of global variables whereever possible in the first case. In case of library functions dealing with pointers, on the other hand, one cannot be sure whether the pointer itself is destroyed after the memory is freed. So setting the pointer to a sane value is a must and cannot be avoided. Torsten
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
