First would this be a check cppcheck would be interested in? Second if I wanted to implement the rule as a performance check. Looking at the wiki section I first noticed a missing Document in the rukes section http://sourceforge.net/projects/cppcheck/files/Articles/writing-rules-3.pdf/download Second is a rule the best way to do this check? Third when I tried the --rule option cppcheck told me it was an unrecognized command line option. I'm guessing that my version of cppcheck wasn't built with PCRE. Or has the command line option changed?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would not implement this as a rule. An addon would be better.
I am not sure if it should be a builtin check or implemented in an addon. I guess you could implement a builtin check pretty quickly in a branch.. and then test it out with the tools/test-my-pr.py script. Then we get some statistics. How much false positives there are is the key.
If people would in general prefer to use s = ""; for stylistic reasons then I don't want that we warn about it. I don't know what people are thinking about this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you orbitcowboy. I guess to me it was more of it looked like something not to hard to add that would be a useful performance check for cppcheck. Personally I was looking at it more from the point of getting some experience at working on cppcheck. I tend to post a bit of the form and would like to try and do some coding. Sort of how do you add a check to cppcheck kind of thing. You know where to start, how to make a test for it and the documentation for it.
As far as performance goes I know it can be a two way street. All things being equal you really should prefer cleaner code to look at. As far as optimizations goes I liked this one because it's not one that a compiler would be allowed to make for you. Take the case of sincos For GCC at -O1 it will change a cos(x) and sin(x) to use the sincos function. The thing is cos(x) and sin(x) look nice and clean. Changing to sincos(x, double sin, double cos) it can mess up the flow of an equation. I can see a need to want to make performance checks more of an add on, because there may be other inputs that are not typical inputs of static analysis tools which could be useful for performance checking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was looking at the current addons and wondering is there a way to add unit test for addons? Also findcasts.py looks like a pretty easy example to follow, but I was wondering if there are any best practices for writing cppcheck addons?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have tests in addons/test for some addons. But those require a special -verify option. I believe it should also work that you create a test source file and inline suppress all the expected warnings. Then run the test with cppcheck --addon=.. --inline-suppr testfile.c .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just seeing this video https://youtu.be/3X9qK7HWxjk It might make a good performance check for cppcheck to recommend string.clear(); over string = "";
First would this be a check cppcheck would be interested in? Second if I wanted to implement the rule as a performance check. Looking at the wiki section I first noticed a missing Document in the rukes section http://sourceforge.net/projects/cppcheck/files/Articles/writing-rules-3.pdf/download Second is a rule the best way to do this check? Third when I tried the --rule option cppcheck told me it was an unrecognized command line option. I'm guessing that my version of cppcheck wasn't built with PCRE. Or has the command line option changed?
I would not implement this as a rule. An addon would be better.
I am not sure if it should be a builtin check or implemented in an addon. I guess you could implement a builtin check pretty quickly in a branch.. and then test it out with the tools/test-my-pr.py script. Then we get some statistics. How much false positives there are is the key.
If people would in general prefer to use
s = "";for stylistic reasons then I don't want that we warn about it. I don't know what people are thinking about this.IMHO, rules can be used to simply spot some issues in large code bases, but you have to be aware that an addon is likely more precise.
Here is a rule file that spots string clearing
Dummy code to test
Lets check if it works
Thank you orbitcowboy. I guess to me it was more of it looked like something not to hard to add that would be a useful performance check for cppcheck. Personally I was looking at it more from the point of getting some experience at working on cppcheck. I tend to post a bit of the form and would like to try and do some coding. Sort of how do you add a check to cppcheck kind of thing. You know where to start, how to make a test for it and the documentation for it.
As far as performance goes I know it can be a two way street. All things being equal you really should prefer cleaner code to look at. As far as optimizations goes I liked this one because it's not one that a compiler would be allowed to make for you. Take the case of sincos For GCC at -O1 it will change a cos(x) and sin(x) to use the sincos function. The thing is cos(x) and sin(x) look nice and clean. Changing to sincos(x, double sin, double cos) it can mess up the flow of an equation. I can see a need to want to make performance checks more of an add on, because there may be other inputs that are not typical inputs of static analysis tools which could be useful for performance checking.
I was looking at the current addons and wondering is there a way to add unit test for addons? Also findcasts.py looks like a pretty easy example to follow, but I was wondering if there are any best practices for writing cppcheck addons?
We have tests in
addons/testfor some addons. But those require a special-verifyoption. I believe it should also work that you create a test source file and inline suppress all the expected warnings. Then run the test withcppcheck --addon=.. --inline-suppr testfile.c.