Timur Tabi wrote: > On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren <gerald.vanba...@ge.com> > wrote: > >> ACK. I don't expect to see variables spring into life in the middle of >> nowhere. > > I don't see what's wrong with that. The advantage is that the > variable is close to where it's being used, so that you can see the > context more easily.
Agreed. In many cases it reduces clutter by eliminating the need for separate declaration and assignment. > I don't see what the value is of limiting the lifetime of the > variable. It frees the variable up for later such blocks to use. As does declaring iterators inside a for loop, but I guess that's forbidden as well. :-) > It's just going to use this for syntax checking. If you define and > initialize a variable at the top of the function, but don't use that > variable until a hundred lines later, the compiler is going to > initialize the variable when it's first used, not when the function is > first entered. Chances are it's not even going to define stack space > for it. Chances are it will allocate all stack space for all variables up front, regardless of where they're declared. >> #ifdef CONFIG_COOL_FEATURE >> { >> u32 myvarrocks = foo * bar * bar; >> >> gd->neato = myvarrocks >> } >> #endif >> >> Is this an acceptable compromise? > > This is what we do today, and I think it's ugly. Yes. But not as ugly as having two #ifdef blocks. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot