| T O P I C R E V I E W |
| jzq740176597 |
Posted - Jan 07 2013 : 02:54:06 AM
Like the title,many times when I read or modify other's code,the member function may should be "const",but the code is not for the bad habit or forget the const.
So VA can offer a function to test a member-function whether can be "const" by check it's imp whether or not modify the "this object".
If not determined, also can notify the user,But many times is work like when "Find references" can indicate with gray or orange icon. |
| 6 L A T E S T R E P L I E S (Newest First) |
| jzq740176597 |
Posted - Jan 12 2013 : 05:33:01 AM
Thanks! |
| feline |
Posted - Jan 10 2013 : 6:24:40 PM
This makes sense, I have put in a feature request to see what our developers make of it. Personally I like the idea, I am just concerned that people will want / expect deeper code scanning. Still, we will see:
case=71722 |
| jzq740176597 |
Posted - Jan 09 2013 : 7:55:46 PM
No,I think this rule is enough. In other words,It's enough for the user.
By this ,the user can Hit 90% functions can be const or not can.
Step back and speak,Just like Find-References function, The Yellow_icon means the variable is modified.And Now ,does VA have deal with all the cases especially the pointer or the reference to variable As parameters to function cann't see the source code ? No,Now the "Assignemnet =" is the key to indicate the change.The "not-determined" state is exsited as least.
Another,try best to qualify with "const" is good program-habit.Even though,the user incorrectly qualify with "const" to the no-const fucntion,The complier will warn it.
In one word,I think this rule is enough,Hope your team can offer such a function, thank you . |
| feline |
Posted - Jan 09 2013 : 12:30:59 PM
This set of rules is fairly simple, I agree I am just concerned it is a bit to limited to be useful. Is this actually going to cover many functions in your code base? If we add a refactoring command to check for a function being a const function people are going to assume it does more checking. I would assume this myself. |
| jzq740176597 |
Posted - Jan 08 2013 : 6:58:14 PM
The rule I advise is:
(1)check the code of this function,if some member modified evidently. e.g. this->m=0 .Etc. Then we get it.
(2)then check the directly called functions,2 parts
<1>member-function if it's const,then definitely don't alter the object.we get it. otherwise,we assume it will alter the member.
<2> no-member function ,if the function's parameter it's this object or this's member ' s no-const reference or pointer .we assume that it will alter the object otherwise it cann't.
I think this rules for the user it's simple and easy to control and make sense and efficient. |
| feline |
Posted - Jan 08 2013 : 1:08:46 PM
I am not sure what to say here. This is an interesting idea, but making it work...
Checking if a member function modifies any of the member variables directly should not be to hard. The problem is any function calls the function makes. You then have to check those function calls. As soon as you start doing this, how deep do you go? How many levels down?
This is static code analysis, and is quickly going to get hard.
Or you ignore function calls, and end up with a feature that does not really do much.
Do you have a lot of simple functions that don't call any other functions? |
|
|
