> Storage concerns are separated and grouped at the top. That's rather circular. That's what defines the style, it's not in itself an advantage or a disadvanta

> Storage concerns are separated and grouped at the top. That's rather circular. That's what defines the style, it's not in itself an advantage or a disadvantage. > Logic code is more compact, helping readability It's slightly more compact, but it harms readability, as I describe at [0]. Using the new style, especially with the const keyword, can make code much more readable. > Stack use can be determined at a glance. It can't, that's up to the compiler. Perhaps all locals will be enregistered. Even if it were true, it's extremely rare to need to do this. > Looking up a variable's type is faster in cases where a variable is used throughout the code block. In certain circumstances this may be true, but there may still be multiple levels you may have to check. For short-lived locals, it will be quicker to look up the type using the new style, as that keeps the declaration close to where it is used. Using a modern IDE, it's a draw - just hover over a local and it will tell you its type. > Reflects that object lifetime of any stack storage object is the same regardless of where it is declared in the code block. That doesn't sound right. That will be platform-dependent. I see no reason a compiler couldn't generate incremental pushes, rather than an upfront block allocation. Also, depending on what the compiler generates, different locals may end up occupying the same place in the stack (at different times), and a given local may be held in different places in the stack at different times. And that's if we're ignoring registers. No matter what we do, we can't rely on the generated assembly looking anything like the source code. Beyond that, it's 'dishonest' about locals' real lifetimes, in a way that can be harmful. Compare: { // Old style int i; int j; i = j; // Undefined behaviour j = 7; } { // New style int i = j; // Compile-time error. 'j' is not in scope. int j = 7; } > "-Wuninitialized" exists, but passing pointer and defining 'default' value style can still cause read-before-write. I'm afraid I don't get what you're saying here. Are you referring to the danger of passing a 'default' value to a function, say, in a way that might be dangerous?