So I have something like this
int age;
for (auto person : persons) {
age = std::stoi(person[0]);
/* Do other stuff with age in this loop*/
}
Other than style, are there any performance benefits to declaring int age = std::stoi(person[0]); inside the loop?
Since you have used the age variable only inside the for loop, you may reduce its scope and declare it inside the for loop only. That way, the compiler doesn't have to remember the variable once you're done with it in the loop.
You should declare it outside the loop only if you intend to use it outside as well.
are there any performance benefits
Because of the "as-if" rule, it's reasonable to assume that there is no performance difference between two equivalent ways of declaring the same variable.
Related
CppCheck finds me some findings like: "The scope of the variable 'x' can be reduced".
What if I have this situation:
int x;
for (int i = 0; i != 10; ++i)
{
x = someFunction();
// ... I use x variable here
}
I think my code is OK. What do you think? Should it change to something like that?
for (int i = 0; i != 10; ++i)
{
int x = someFunction();
// ... I use x variable here
}
In the second code a variable x is defined for all iteration... Isn't not ok (not optimal), I guess..
The position of an int declaration has no performance impact, so Cppcheck is right when raising this style issue. This style issue can be applied to non-trivial types as well,
for (int i = 0; i != 10; ++i)
{
MyType x = someFunction();
// ... I use x variable here
}
since constructors tend to be as equally efficient as assignments. As of Version 1.65, Cppcheck seems not to distinguish between trivial and non-trivial types.
But don't blindly follow such style suggestions, there will be cases of non-trivial types where assignment is more efficient than construction. (As usual: if in doubt about performance, measure!)
Edit: a style consideration
The second variant is better in style as it combines declaration and initialization:
This often saves you from writing (or reading) a comment that is not very meaningful.
Sometimes you can also add const, which prevents you from accidental changes
If variable x is not used outside the loop then the second approach is much better. And there is not the slightest problem with the optimization of the code. The memory for the variable is allocated only once in the loop.
As others have mentioned, for trivial types it is unlikely to make significant performance impact.
However, you should also consider that, by reducing scope, you aid readability by having the declaration closer to usage, and possibly more importantly, make it easier to refactor.
Both of these could be important when considering maintainability.
We all know we should keep functions short and well refactored, but we have all seen those 5000 line long monsters, where a variable was declared at the top, and used once, 3789 lines in. And if you haven't, pity the rest of us.
I am trying to optimize a program in C++ I have implemented and a question came in mind...
Where should I declare a variable if I have a repetitive structure using it?
For example:
//1-> int sum;
int matrix[10][10];
for(int i = 0; i < n; i++){
//1-> sum=0;
//2-> int sum=0;
for(int j = 0; j < n; j++)
sum += matrix[i][j];
printf("%d ", sum);
}
So which is better/recommended? Should I declare it at the beginning //->1 outside of the repetitive structure or it is fine if is redeclared //->2 at each iteration?
My guess is that declaration takes a very small time (milliseconds or less) but if you redeclare it in a repetitive structure big enough (or inside multiple structures) each redeclaration will add up to some extra seconds.
For an int it just doesn't matter. For a type with a non-trivial constructor or destructor, under scheme 2 it would be constructed and destroyed each time through the outer loop, and that would be potentially time-consuming.
It doesn't matter. The stack (reserved space in memory) is allocated all together in the beginning of the function/method. If it's an object, the contructor and destructor will be called somewhere in the scope of your loop. But for elemental types, there's absolutely no difference.
As others have already stated, it mostly doesn't matter for an int.
There are only two things to concern yourself with here:
Readability
Scope
If the int is declared right before the for loop rather than as the first line of the for loop, readability is probably about the same. Plus, many compiler's will have a shortcut for jumping straight to a declaration.
As for Scope, if you don't need the variable outside of the loop, putting it inside helps make sure you don't accidentally use it outside the loop in any way. If you do need it outside the loop, you really don't have much choice.
A note on my personal preference which combines both scope and readability issues, when I write code, I prefer having EVERY variable I will use in a given scope declared at the beginning of that scope. Any variable I use in main is declared at the top of main. Any variable used in a function is declared at the top of that function. Any variable used in a loop is declared at the top of that loop. Any variable used in a if statement is declared at the top of that if statement. I personally make very few exceptions. So in your case, if the scope of sum is limited purely to your for loop, I'd declare it as the first variable of the for loop. If sum needs scope outside of the loop, I'd declare it at the top of whatever function you're in and give it a far more descriptive name.
This question already has answers here:
Unnecessary curly braces in C++
(14 answers)
Closed 9 years ago.
I came across one project,where I found some code which I is not understandable to me. I just started with C++, so it seems like a big problem for me. I am providing few lines of my project,which I am not able to understand.
class abc
{
public:
//some stuff
abc();
};
abc::abc()
{
int someflag = 0;
//code
if(someflag == 0)
{
do
{
//few strcpy operations
{ //(My Question)Without any condition braces started
//variable initialization
}
}while(condition);
}
}
Now my questions...
What we can achieve by doing this operation?
What is happening in inside braces of do-while loop?
What is the scope of the initialized variables (I mentioned) inside
do-while loop?
Is it C++11?
Help me to understand this.
What we can achieve by doing this operation?
You introduce a scope block for the variables inside.
What is happening in inside braces of do-while loop?
See above.
What is the scope of the initialized variables (I mentioned) inside do-while loop?
The variables go out of scope at the end of the braces, they're there for that sole reason. One use case I can think of for this is a scoped_lock or something similar to it for multi-threaded applications.
Is it C++11?
No.
Even in C you can open a brace in any point where a statement is permitted.
This allows to declare and use new variables without interferring with the enclosing scope. For example:
... code before ...
{
int i = 0, sum = 0;
while (i < n) {
sum += dothis(data[i++]);
}
dothat(sum);
}
... code after ...
the two variables i and sum have nothing to do with variables with the same name in the enclosing scope: these two variables are created when entering the block and destroyed when exiting the block (while instead n and data are defined outside). This can help readability by avoiding separation between declaration and use or between declaration and initialization (in old C you were not allowed to put a variable declaration right before use... all locals were required to be declared at start of function: an annoying problem if you don't know yet the value to give them).
If you are in C++ and these block-local variables have a class type the constructor is called when entering the block (not when entering the function) and destroyed immediately when exiting the block. This can be very useful for example for locks
{
Lock mylock(resource);
use_resource();
}
Here are your answers:
Ans 1,2. This is used to define a new scope.
Ans 3. The scope of variables end as soon as the control moves out of the block
Ans 4. Probably the coder comes from C background and it is not particular to C++11 as in C, variables can only be declared at the beginning of a new scope.
Please look at THIS and THIS for further reference.
There are five types of scopes in C++
Function
File
Block
Function Prototype
Class
The code which you shared shows 'block scope'
Block scope
Blocks are portions of C++ code contained within curly braces( {....} ). Identifiers declared within a block have block scope and are visible from their points of definition to the end of the innermost containing block. A duplicate identifier name in a block hides the value of an identifier with the same name defined outside the block.
A variable name declared in a block is local to that block. It can be used only in it and the other blocks contained under it.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Can I use blocks to manage scope of variables in C++?
I came across some C++ code that resembled:
int main(void) {
int foo;
float qux;
/* do some stuff */
{
int bar;
bar = foo * foo;
qux = some_func(bar);
}
/* continue doing some more stuff */
}
Initially I thought that perhaps the original author was using braces to group some related variables, but being that the system under design doesn't have an abundance of memory I thought the author might have had the intention of having bar's scope resolve and any variables with in go away rather than have them around for the entire enclosing (foo's) scope.
Is there any reason to do this? It seems to me this shouldn't be necessary and that any modern compiler makes this unnecessary?
It seems to me this shouldn't be necessary and that any modern compiler makes this unnecessary?
Yes, modern compilers will optimize the memory usage in cases like this. The extra scope won't make the code faster or more memory efficient.
However, they can't optimize objects with destructors with side-effects as that would change the behavior of the program. Thus, this makes sense to do for such objects.
Is there any reason to do this?
It is useful to group related code together. You know that variables declared inside the braces won't be used anywhere else which is extremely helpful to know.
If you do that multiple times in a single method, that could result in that method taking up less stack space, depending on your compiler. If you're resource limited, you might be on a microcontroller, and their compilers aren't always as full-featured as x86 compilers.
Also, if you do that with full classes (instead of ints & floats), it lets you control where the destructor is called.
class MyClass;
int main(void) {
int foo;
float qux;
/* do some stuff */
{
MyClass bar;
qux = some_func(bar);
} // <-- ~MyClass() called here.
/* continue doing some more stuff */
}
In case of C/C++ one can try to limit conflicts between names (having function that is so long that requires one to scope variable this way is bad idea...) i.e. if there are multiple bar in the same function than scoping them this way will let one make sure they don't collide/override each other.
Normally scope inside function does not impact stack allocation size - stack is pre-allocated for all local variables irrespective of scope.
If the code is really like you've shown, it's probably pretty much pointless. Most compilers I've seen allocate the space for all local variables on entry to the function, and release it on exit from the function. There are a few other possibilities though.
If what you've shown as bar was an object of some class type (especially something with a destructor), the destructor would run on exit from the scope, even though the space wasn't released until later.
Another possibility is that there were really two inner scopes:
int main() {
// ...
{
// some variables
}
// ...
{
// other variables
}
}
In this case, the space for the local variables will be allocated on entry to main -- but, some variables and other variables will (typically) share the same space. I.e., the space that's allocated will be enough to accommodate the larger of the two, but will not (normally) be the sum of the two, as you'd use if you defined all the variables in main's scope.
intention of having bar's scope resolve and any variables with in go
away rather than have them around for the entire enclosing (foo's)
scope
This could be one (unimportant & legacy) reason.
The other reason is to convey it to the reader that int bar is just used within this scope to have a very small functionality (kind of function inside function). After that there is no use of bar.
Your code is equivalent of:
inline void Update (int &foo, float &qux)
{
int bar = foo * foo;
qux = some_func(bar);
}
int main ()
{
...
Update(foo, qux);
...
}
Most compiler will optimize call to Update() inside main() and inline it, which generates similar to what you posted.
It is likely meant to aid the programmer, not optimize the output, as a modern compiler is certainly smart enough to see a temporary variable is only used once.
On the other hand, for the programmer it adds a logical separation, it means "these variables are only needed for this code," and perhaps also "this code does not affect other code in this function."
I have a vector in a header, like so:
extern std::vector<Foo> g_vector;
In the associated cpp file I have this:
std::vector<Foo> g_vector;
I also have a class Bar, and in it's constructor it will add some stuff to g_vector, like so:
Bar::Bar(/* stuff */)
{
// do things
std::cout << g_vector.size() << std::endl;
g_vector.push_back(somefoo);
std::cout << g_vector.size() << std::endl;
}
If I declare a Bar inside a function, like a sane person, it appears to work fine. However, if I want to declare a Bar outside of a function, weird things happen. For example, I have a Bar declared in MyFile1.cpp and in MyFile2.cpp, and because of my cout statements in Bar I can see the Foo get pushed into the vector, but when the next Bar runs its constructor the vector's size is 0 again. In other words, my output is
0
1
0
1
What gives? Just to be extra double sure, I also tried printing out &g_vector to make sure it was actually push_backing into the right vector, and the addresses all match. For what it's worth, it doesn't matter what order these things go in to the vector. I'm not concerned with the initialization order or anything.
Not sure what the issue really is, but I guess the following pattern will help solve it: define an accessor to the global variable and allocate it as a static function variable as shown below.
In the header file:
std::vector<Foo> &getGlobalVector();
In the cpp file:
std::vector<Foo> &getGlobalVector()
{
static std::vector<Foo> s_vector;
return s_vector;
}
This pattern is inspired from Andrei Alexandrescu's "generic singleton" implementation in Modern C++ design.
I've taken the habit of systematically using this pattern whenever I fell upon an existing global variable while maintaining existing applications (or in the rare occasions I actually chose to use one myself), and it may have helped in eliminating a couple of hard-to-reproduce bugs in said applications.
At any rate, this should really help avoiding any multiple-initialization or order-of-initialization related issue.
Order of initialization of global values is not defined.
Read here about the static initialization fiasco.
When you declare Bar in a function - the g_vector will be initialized before, because its promised to be initialized before the program runs. If Bar is a global variable - then you have a problem.