Initialize variables within if and switch statements
Beginning with C++17, if and switch now have initialization syntax, much like the for loop has had since C99. This allows you to limit the scope of variables used within the condition.
How to do it…
You may be accustomed to code like this:
const string artist{ "Jimi Hendrix" };
size_t pos{ artist.find("Jimi") };
if(pos != string::npos) {
cout << "found\n";
} else {
cout << "not found\n";
}
This leaves the variable pos exposed outside the scope of the conditional statement, where it needs to be managed, or it can collide with other attempts to use the same symbol.
Now you can put the initialization expression inside the if condition:
if(size_t pos{ artist.find("Jimi") }; pos != string::npos) {
cout << "found\n";
} else {
cout << "not found\n";
}
Now the scope of the pos variable is confined to the scope of the conditional. This keeps your namespace clean and manageable.
How it works…
The initializer expression can be used in either if or switch statements. Here are some examples of each.
- Use an initializer expression with an
ifstatement:if(auto var{ init_value }; condition) { // var is visible } else { // var is visible } // var is NOT visible
The variable defined in the initializer expression is visible within the scope of the entire if statement, including the else clause. Once control flows out of the if statement scope, the variable will no longer be visible, and any relevant destructors will be called.
- Use an initializer expression with a
switchstatement:switch(auto var{ init_value }; var) { case 1: ... case 2: ... case 3: ... ... Default: ... } // var is NOT visible
The variable defined in the initializer expression is visible within the scope of the entire switch statement, including all the case clauses and the default clause, if included. Once control flows out of the switch statement scope, the variable will no longer be visible, and any relevant destructors will be called.
There's more…
One interesting use case is to limit the scope of a lock_guard that's locking a mutex. This becomes simple with an initializer expression:
if (lock_guard<mutex> lg{ my_mutex }; condition) {
// interesting things happen here
}
The lock_guard locks the mutex in its constructor and unlocks it in its destructor. Now the lock_guard will be automatically destroyed when it runs out of the scope of the if statement. In the past you would have had to delete it or enclose the whole if statement in an extra block of braces.
Another use case could be using a legacy interface that uses output parameters, like this one from SQLite:
if(
sqlite3_stmt** stmt,
auto rc = sqlite3_prepare_v2(db, sql, -1, &_stmt,
nullptr);
!rc) {
// do SQL things
} else { // handle the error
// use the error code
return 0;
}
Here I can keep the statement handle and the error code localized to the scope of the if statement. Otherwise, I would need to manage those objects globally.
Using initializer expressions will help keep your code tight and uncluttered, more compact, and easier to read. Refactoring and managing your code will also become easier.
