| T O P I C R E V I E W |
| jmpep |
Posted - Jun 17 2011 : 09:27:15 AM
Hi! Just a quick suggestion.
In our code base we have a lot of methods that use output parameters (for example when a function has to return several things, as usual). For performance considerations, these output parameters are not pointers, but references. For example:
calculate_b_from_a( const Object & a, Object b );
It's easy to tell which parameters is for input and which for output from the signature of the method declaration (thanks to the const keyword), but not from a method call:
calculate_b_from_a( a, b );
We would be delighted if Tomato could find out which method is const and which is not, and colour the parameters in the method call differently. That way we could see which parameters will be filled by the method and which not at first glance.
PS: Congratulations on this excelent software, by the way :) |
| 4 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jun 21 2011 : 10:06:54 AM
If I understand your situation correctly, you could do a Find References on the variable in question, and once case=9955 is done, look for any references that are highlighted as modified, or possibly modified.
There should not be any references highlighted as modified, so you would be able to focus on the possibly modified references. These should be any function calls where the variable is passed by reference or pointer, so allowing it to be modified. |
| jmpep |
Posted - Jun 21 2011 : 06:25:35 AM
Thanks you very much for the prompt reply! :)
I know VA shows the function signature, but albeit useful it does not assist much in certain scenarios.
For example, imagine we are debugging, and we (finally!) find out that a variable have changed its value within a (rather large) function. Now we want to know where. Unfortunately, the variable might have been changed not only in an assignment sentence ("variable = val"), but also anywhere where it is used as parameter to a function. Well, of course, only when it is used as an output parameter, but since we have no way of telling when it is an output parameter and when an input one...
In that case, if VA provided a cue it would be wonderful.
Anyway, I always meant this feature to be an option that could be enabled. I understand that there is code that makes no use of const at all, and thus there is no way of telling (automatically) which parameters are for input or output.
Finally, as for the Find References Result, I am afraid I am unable to see how that would help with this issue... maybe I didn't understand it fully?
|
| feline |
Posted - Jun 18 2011 : 09:13:33 AM
Thinking about this some more, are you aware that if you place the caret into the function name, VA shows the function signature in its definition bar? This is normally at the top of the editor:
http://www.wholetomato.com/products/features/definition.asp
My concern here is that if we tried to make this change, then why is it only limited to function calls? Will the next reply to make non const local variables, parameters to functions, etc, a different colour? We are trying to avoid the situation where every symbol is a different colour, since this is likely to confuse more than it helps. |
| feline |
Posted - Jun 17 2011 : 5:50:31 PM
I am not quite sure what to say here. This is a very interesting idea, but it is only going to be helpful some of the time, since it requires / assumes that any parameter that is not going to be modified is labelled as const. Personally I feel this is how code should be written, but I am aware a lot of code is not written this way.
We are considering highlighting references in Find References Results that might be modified in a 3rd colour, which is the same idea, just in a more limited scope:
case=9955
One of the practical problems here is that this requires VA knowing which overload is being called. Currently VA cannot work out which overload you are calling, so this cannot really be applied to overloaded functions at this time. Also we need to keep our syntax highlighting code very "simple", otherwise it cannot run fast enough to keep up with scrolling and editing. Having to look up every function signature before deciding the colouring could be a significant overhead. |
|
|
