toString

[Michelle Long]

On Monday, 31 December 2018 at 15:39:05 UTC, Rainer Schuetze 
wrote:
>
>
> On 31/12/2018 11:13, Michelle Long wrote:
>> Display variables in the watch shows the variables in a flat 
>> list. Can we just get an override for toString or some other 
>> method to change what is displayed?
>> 
>> Surely this can be accomplished?
>> 
>> Even if it means creating an external DLL that Visual D can 
>> read and choose the right function and use it to take the 
>> object and return a string and simply display that string 
>> instead of whatever Visual D is generating internally?
>> 
>> struct S
>> {
>>    int x;
>> }
>> 
>> 
>> Somewhere
>> 
>>    auto S_toString(S s)
>>    {
>>       return "S: "~s.x;
>>    }
>> 
>> Should be very simple to do. Visual D just uses that function.
>> 
>> 
>
> What you can do now when using the VS debugger with the mago 
> extension (and not mago selected as debug engine):
>
> struct Size
> {
> 	int w;
> 	int h;
>
> 	const char* toDebug()
> 	{
> 		import std.conv;
> 		import std.utf;
>
> 		return toUTFz!(char*)(to!string(w) ~ "x" ~ to!string(h));
> 	}
> }
>
> int test()
> {
> 	Size sz = Size(10, 20);
> 	return sz.w * sz.h; // Breakpoint here
> }
>
> Run to the breakpoint and then add watch "sz.toDebug()" to 
> execute the function and display the result.
>
> Some limitations apply:
> - no arguments but the implicit this or context pointer (i.e. 
> delegates
> work, too)
> - doesn't work with slice return values for x64 due to 
> incompatible ABI
> - you have to manually reevaluate in the watch window due to 
> possible
> side-effects
> - the example above currently seems broken for x86, not sure why

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


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")