4 ms·
That's sorta the point... the init isn't the branch condition. It gives terser syntax to a common patter where you want to scope something into the body of an i
by jacobparker 9y ago
That's sorta the point... the init isn't the branch condition. It gives terser syntax to a common patter where you want to scope something into the body of an if statement.
{
std::unique_ptr<T> x = foo();
if(x->something()) {
// use x
}
}
// x out of scope, destructed
becomes
if(auto x = foo(); x->something()) {
// use x
}
// x out of scope, destructed
It's makes it easier to read the lifetime of x (an important thing you have to manually keep an eye on in C++ in many cases), and to determine what is in scope outside of the if statement. It's analogous to for-loops vs. doing loops "manually" with while. You're just used to for-loops by this point (if you don't like for loops then ok :).)
C# is also getting (has got?) this feature.
- tcbawo 9y agoIf I'm reading the paper right, the init statement could be any expression-statement or simple initialization. So, modifying unrelated, externally scoped variables in the init would be legal. I don't see this improving readability.
- roel_v 9y agoWell, "#define if while" is also legal, and doesn't improve readability either. Like most features, when abused, they're a liability.
- rleigh 9y agoIt's no different than the init and conditional parts of a for loop. Do people abuse for loops to do unrelated tasks? Not really. It does improve readability. If you've ever had to have a series of conditionals in their own braces to keep the init variable in its own scope, then you have a use for this. The alternative might be having foo1, foo2, foo3… all in the same scope, and it's too easy to use the wrong one. This keeps things specifically constrained to the scope in which they are used, which improves safety and correctness, and I think also readability once you adapt to it. Yes, it could be abused, but I don't think that's a reason not to use it for its intended purpose.
- tcbawo 9y agoPeople mess up for loops a lot! That's why range-based for and the STL algorithms library are so useful. I agree having multiple fooX variables in scope is bad. In practice, I've found that either many of these return types are identical, so variables could be reused, or the logic flow could be organized in a more straightforward way.
- rleigh 9y agoI wouldn't want to reuse a variable for multiple purposes though; that can lead to unintentional use of the wrong value. At least this way you ensure that can't happen. And agreed that people mess for loops up, and range based loops are better. My point was only related to the syntactic precedent for coupling an initialiser and conditional in a statement.
- tcbawo 9y agoGenerally, variable reuse is bad. But for something like an error flag that immediately causes function exit and is never referenced again, I wouldn't raise an objection in a code review.
- dkarl 9y agoTo expand on this for non-C++ programmers, scope is important in C++ because it is used for resource management via RAII [1]. In most languages, in most cases, scopes within a function are used to enhance readability rather than to specify program logic, so a feature like this would add more complexity than it removes. [1] http://en.cppreference.com/w/cpp/language/raii http://en.cppreference.com/w/cpp/language/raii
- deeringc 9y agoWhat makes this really nice is that the variable is also still in scope in the corresponding else block.