debugger blues

[cy via Digitalmars-d]

On Sunday, 27 March 2016 at 15:40:47 UTC, Marco Leise wrote:
> Is it just me? I've never heard of a programming environment, 
> let alone a system programming language providing that 
> information.

Well, not by default certainly. It is a bit pie-in-the-sky, but 
only because it slows everything down. It's got the same cost as 
profiling. Many languages, even C in some cases, have support for 
this. With gcc for instance, if you use -finstrument-functions 
then it calls __cyg_profile_func_enter before every function call 
and __cyg_profile_func_exit afterwards. That can be used to 
accumulate _totals_ of how many times a function was called 
(profiling) but it can also just dump the called functions in 
order.

I certainly would be shocked as heck if a debugger could take 
non-instrumented code and add all that tracing and/or profiling 
stuff, but stranger things have happened in the murky realm of 
code debugging.

> "DOESN'T LET YOU PUT SPACES BETWEEN THE ARGUMENTS" is just 
> silly and factually wrong.

No, it's factually true. You can provide arguments that have 
spaces in them, but there is no way to put spaces between the 
arguments to your logging function. I would expect that the 
logger would be called with the arguments provided, but instead 
the logging code uses a private function to stringify and 
concatenate all the arguments, and provides it to the logger as 
one single opaque string. This is certainly something that could 
be improved.

What I did was write my own logging framework, that joins 
arguments with spaces in between, and provides that as a single 
argument to std.experimental.logging. But that requires me to 
duplicate all the template boilerplate (func = __func__, file = 
__file__, line = __line__ etc) so all the code in 
std.experimental.logging to do that can't be used, reducing 
std.experimental.logging to basically nothing other than writeln.

> If you ask for a *guarantee* of no copy on struct return, then 
> you are right.

I wish I was right. There are still some gotchas there, that I 
don't fully understand. Things like:
> 	BigStruct ret = returnsBigStructToo();

look the same as things like:
> 	BigStruct ret = returnedbigstruct;

but the latter is actually a copy. D making paretheses optional 
for properties makes it even more confusing.

> A a = b.myA // copy or emplacement?

But even taking that into account, I've had mysterious situations 
where the pointer to a returned structure changed, from within 
the function to without, without any apparant copying going on. 
When member functions raise assertions if that pointer was 
different... it's just not workable. I don't actually know why 
copying is occurring in many cases, or pseudo-copying 
or...whatever, so I can't really tell you what I'm talking about 
exactly.

I should ask that as a separate question...