-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix compiler warnings #140
base: master
Are you sure you want to change the base?
Conversation
The grammar corrections are appreciated, but we are trying to be consistent with the variable naming and are following the book for it, please do not change it. |
Just to be sure. You are referring to all changes in variable names or just the two for-loops, both using i as a counter? |
ATTENTION: Please take a close look at the lambda in optimizer.h:928 The parameter was overshadowing the capture which is interpreted in variable ways on different compilers. I made a guess on the intended behavior which might be very wrong.
I was referring to the for loops, we are trying to keep the 'i' consistent. |
OK, so the lambda should look as follows?
In that case I am confused as to why the lambda takes a parameter for the call if it doesn't use it. |
Yes, that is how it should used. But I too am confused regarding your question. Which parameter are you referring to, because every parameter being captured is used inside the lambda function I think. |
Maybe we have a misunderstanding here. All values captured by the lambda are used, that I agree with. The thing is that the way the std::function object is defined, it would have the following function prototype (captures of the lambda are not relevant here):
So the function, when it is invoked, needs to be passed an Eigen::VectorXd object. Since we are not using this passed parameter in the function, I was wondering why it is needed in the first place. |
Builds silently on MSVC with /W4
ATTENTION: Please take a close look at the lambda in optimizer.h:928
The parameter was overshadowing the capture which is interpreted in variable ways on different compilers. I made a guess on the intended behavior which might be very wrong.