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...
