One could implement tail call optimization so that the stack trace still retains information about the where the tail calls where, but it will eventually consume all memory if there is an indefinite amount of tail calls, and the stack trace would likely be unreadable, due to how large it was, even if steps were taken to compress it visually. It would be less of a stack trace, and more of a complete print out of the entire execution of your program from the moment it started.
>>9 but it will eventually consume all memory
I'm of two minds on this. The shitposter in me wants to agree on the basis that all Java applications are designed to do just that, thus printing the tidy stack trace.
More seriously though, implementers don't feel right about doing this. It compromises the optimization (adding a factor of NaN overhead) since proper TCO executes in constant space. It also adds complexity to the code, all for the sake of recording the stack behavior of what is likely to be some short bodied calls anyway -- you won't save much space in the common case, you'll be slowing down all tail calls, and you will have complicated the code.
tl;dr -> Usually either you highly value the stack information in which case you kill off TCO or you are willing to sacrifice it for the memory savings. Going bipartisan just makes trouble, wastes time and and saves roughly nothing.
Name:
Anonymous2011-10-20 1:10
I still don't know what tail-recursion is, is this tail-recursive?
#include <stdio.h>
#include <stdlib.h>
#define lambda(...) \
({ \
int (*__lambda_fptr) (__VA_ARGS__); \
int __lambda (__VA_ARGS__)
Yeah, it's something I would only consider using for debugging purposes. Although even, then, I doubt the resulting stack trace or a normally tail recursive program would be very readable.
In the optimized case you're going to have one call where there were arbitrarily many, and if it's mutually recursive you will not know which calls were involved, save for one.
Not really a big deal in my opinion, a debugger could potentially pick it out and make a note, or if you understand the code already you will know what's going on. The trouble arises when you have an issue within that code somewhere and the failure manifests at a distance. That's hard to assess from the stack trace, and casual use of a debugger would be useless too.
Name:
Anonymous2011-10-20 8:33
>>10,13-14
You can always kill the TCO by wrapping the tailcall with the identity function, no need for compiler switch magic:tailcall() -> id(tailcall()).
Now you get tailcall in the stack trace, and no id because it is TCOed away.
Bump because the frontpage is full of spam.
Name:
Anonymous2011-10-20 8:48
>>11
That's one of the most ugliest pieces of code i've ever seen
Name:
Anonymous2011-10-20 10:03
>>17
That is C/C++ baby! And you havent seen BOOST's "lambda" yet.
Name:
Anonymous2011-10-20 10:18
>>18
It's C, cretin. And Boost uses templates, not compiler-dependent bullshit.
Now kindly go back to /g/, where you clearly belong to.
boost is a pile of shit.
Want to do the exact same thing as printf() but have it be a hundred times slower, both in compile time and execution time? No problem, just add 36275 source files yes, that's the actual number of source files in the current boost distribution (378MB of source) sure hope there aren't any typos! to your project and use boost::format(). Optimized!
Now you should really should go back to /g/, cretin.
>>24
Ironically, Boost was developed to make C++ programming easier. However, Boost is mainly abusing Templates to no end, thus not only raping the processor when you compile it, but also making C++ slow as fuck.
>>19
This is nonsensical, if you are using a pure ANSI-C compiler to compile GNU-C you're most likely going to get errors. It's not compiler dependent cruft though, it's just a different language. Doing that is like trying to compile ocaml code with a Fortran compiler and then complaining that everything is a compiler specific extension. Compiling C++ code with an ANSI-C compiler usually won't work either, because they're different languages, I hope you've had enough examples to realize your mistake.
Name:
Anonymous2011-10-20 13:53
>>28
I said C, not ANSI C, that means, I didn't specify anything, neither ANSI C, nor GNU C.
And didn't I already tell you to move your autistic ass back to /g/?
>>29 I said C, not ANSI C, that means, I didn't specify anything, neither ANSI C, nor GNU C.
What is your point? If you don't refer to a specific standard compiler dependent cruft is nonsensical as you don't have any standards to define what is an extension or not.
The program in >>11 is GNU-C, it's certainly not ANSI-C, and if you use C to refer to something undefined it's undefined whether it's C.
You seem very confused, it's natural to be if you're quite unintelligent and you don't understand what you're talking about. Don't worry though, I'm here to help those with lesser minds.
And didn't I already tell you to move your autistic ass back to /g/?
No, you hadn't responded to any of my posts before.
Name:
Anonymous2011-10-20 14:21
Will the real Zhivago please stand up so I can shoot him in his fucking face?