> A) Under any decently optimizing compiler, it's not more efficient. Here you are right. My fault. > B) To shut up bogus use-before-def warnings from dumber compilers (and > we *never* want to disable use-before-def warnings). Here you are right... sometimes someone have to write code and deal with dumb compilers > C) Because sometimes code is very complex, and under *modification* > it's very easy to miss a new path in the code in which a local > vrbl is suddenly not defined before use. This isn't a nuisance > in C, it's a disaster. Initializing vrbls in complex C code is > basic defensive coding practice. > ... You can do whatever you like in *your* code, > but in the *Python* code base we try not to push compilers to their limits, > let alone readers' brains beyond them <wink>. I accept your reason, primarly thinking of person with dumb compilers... only one more question. The smart compiler now cannot help in this? Cannot be a use-before-def warnings warn of a smart compiler a better way to find a new path instead of writing a lot of test for null value of a pointer? To push the compilers to their limits is just a build problem, no? I simply write too few C code for being an experienced C writer, so It's only my last curiosity (as I think I'm going a little OT ;) Paolo Invernizzi paoloinvernizzi at dmsware.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4