toString

[Michelle Long]

On Thursday, 3 January 2019 at 11:44:11 UTC, Rainer Schuetze 
wrote:
>
>
> On 01/01/2019 17:57, Michelle Long wrote:
>> On Monday, 31 December 2018 at 15:39:05 UTC, Rainer Schuetze 
>> wrote:
>> 
>> Ok, I switched to visual studio debugger added a watch then 
>> ran it.
>> 
>> When I initially run the program I get:
>> 
>> sz.toDebug()    D0022: Error: Function call may have side 
>> effects
>> 
>> and when I refresh I get
>> 
>> sz.toDebug()    D0017: Error: Calling functions not implemented
>
> This error is shown only by the mago debug engine, not the 
> extension to VS. (You might have changed the wrong 
> configuration, happens to me quite often.)
>
>> 
>> 
>> Also, this wasn't really the solution I was looking for 
>> because the point as to optimize the visual data flow of the 
>> objects in the locals and auto's window.
>> 
>> It would be better if such a function was called 
>> automatically. I realize that side effects are a problem but 
>> that is on the programmer IMO.   Maybe just require it to be 
>> pure? In fact though, maybe side effects could be useful in 
>> some cases.
>> 
>> Basically I use the locals mostly so I can quickly see values 
>> of data... sometimes too much information is shown that is not 
>> relevant since the members are all listed. Usually this 
>> obscures some piece of information that is actually relevant 
>> because their is not enough visual room. Hence, being able to 
>> control what is shown is pretty important to make debugging 
>> quicker. Having to go add a watch and revaluate every time 
>> significantly slows things down.
>> 
>> If this basically works with the watch window then surely it 
>> would not be too much trouble to get it to work with the 
>> locals? (assuming you have control over the side effects issue)
>> 
>> It could be an optional "feature": ("Enable Locals toDebug")
>> 
>
> Yes, we could single out some class/struct member function that 
> can be called by the debugger automatically if it exists. It 
> might have bad side effects, though, especially if called on 
> uninitialized pointers.

Another idea long these lines is to automatically evaluate 
functions of types that take no inputs.

struct X
{
    int x;
    int foo(bool test) { return x; }
}

Here foo can be evaluated. In the watch window it shows up as a 
function but it then this require evaluation manually which 
requires editing code. Having the debugger automatically evaluate 
it makes it much easier.

I realize that side effects could pose a big problem here... 
ideally they would just be caught and ignored...

Not sure if VD can add some button to the watch window list that 
one could simply click on to evaluate on this(if not null)?

The idea is having to add code simply to see the value of the 
method only to have to remove that code later.

X a;
int val = a.foo(); // < this line can be avoided if the debugger 
would just show us the value it gets. It already shows us the 
address and other info but not the value which is the most 
important. It could show the value as a child element and require 
evaluation.

This might be less feasible but still a useful feature.