Re: RFC: MI - Detecting change of string contents with variable objects

[Vladimir Prus <ghost@cs.msu.su>]

On Friday 22 December 2006 10:12, Nick Roberts wrote:
>  > > Because -var-evaluate-expression uses varobj_get_value so they will always
>  > > return the same value?
>  > 
>  > Then, there are two solutions:
> 
> We seem to be agree that the patch does the right thing and are just talking
> about implementation details.

Yes.

> 
>  > 1. Make c_value_of_variable and friends accept struct value as opposed to
>  > taking struct varobj.
> 
> c_value_of_variable, as it's name implies, requires a struct varobj as it's
> argument.

You can renamed it to anything you want, say "c_format_value", or whatever.

>  > 2. Extra the part of c_value_of_variable that you've based your function on
>  > into a separate function. Make both c_value_of_variable and install_new_value
>  > call the new function.
> 
> value_get_print_value is quite a small function.  After you've wrapped
> some statements in if clauses and worked out how to call them with a
> common argument, I can't see that you would gain much.
> 
>  > I'm not sure which approach you find better, but I don't think copy-pasting
>  > is a solution to anything.
> 
> Clearly it is *a* solution, it's just a question of whether it's the *best*
> solution in this case.  Anyway, it's not a straight copy-paste (the asserts are
> removed, for example).  

Probably it's perfectionism, but if we want -var-update to return a varobj if the
result of -var-evaluate-expression would be different, then we must execute 
the same code as for -var-evaluate-expression when deciding if the value has changed.
If you run some other code, however similar *now*, it's very likely that soon things
will break.

> I think if you look through the code you'll find 
> numerous examples where one section of code is a slight variation of another.

Yes. I'd like to remove all such cases.

- Volodya