What's wrong with the goto statement?
Pages: 12
| I wish it was the nuclear bomb option, but sadly it's the more tame of the two. |
-Pax
Well nuclear bombs are now so simple and easy that C++ probably can create one (Or a virus equivelent to one). Sorry I don't really know if C++ is good for viruses, but I don't intend to be making any. :D
@xorebxebx
What is TCO and RCO optimization ?
I have a tree type data structure (do not know what it is called in c++ lingo) and I use recursion extensively to travel up and down the tree. For the moment, it seems to be working great. But perhaps in future the depth of this tree might increase significantly. I am uncertain as to how it will affect my code.
I have a very clear way of avoiding recursion for this particular case. As a preprocessing step, i am also computing the path from leaf to the root. However, the implementation itself might get involved without using recursion.
Any comments ?
What is TCO and RCO optimization ?
I have a tree type data structure (do not know what it is called in c++ lingo) and I use recursion extensively to travel up and down the tree. For the moment, it seems to be working great. But perhaps in future the depth of this tree might increase significantly. I am uncertain as to how it will affect my code.
I have a very clear way of avoiding recursion for this particular case. As a preprocessing step, i am also computing the path from leaf to the root. However, the implementation itself might get involved without using recursion.
Any comments ?
Sometimes the nature of the problem lends itself to recursion is the way to go for easy understanding and coding. Trying to make it iterative will require more lines of code and readability suffers even. Traversing a tree data structure is one ideal candidate where recursion is what I will use.
closed account (EzwRko23)
TCO - tail call optimization
TRO - tail recursion optimization (a special case of TCO)
These optimizations change recursive code into a loop. For them to work, the recursive call must be the last operation in the function. Beware of destructors - you are not allowed to put anything non-trivial like std::string on the stack, or the TCO won't be possible. Anyway, this is rather not useful in C++, because you cannot rely on the compiler to perform them. Some compilers will, some won't - this is not a part of the standard.
TRO - tail recursion optimization (a special case of TCO)
These optimizations change recursive code into a loop. For them to work, the recursive call must be the last operation in the function. Beware of destructors - you are not allowed to put anything non-trivial like std::string on the stack, or the TCO won't be possible. Anyway, this is rather not useful in C++, because you cannot rely on the compiler to perform them. Some compilers will, some won't - this is not a part of the standard.
Last edited on
...but it will be part of C++0x, IIRC. I'm looking forward to it, since proper tail-recursion is something I want very badly.
closed account (EzwRko23)
Duoas - link, or it didn't happen. I haven't heard they added a keyword for TCO in C++0x...
Crud, I can't find any. I thought I had read it somewhere that it would be available (via a keyword) but I could have been looking at Tcl, come to think of it... Alas.
http://docs.activestate.com/activetcl/8.6/tcl/TclCmd/tailcall.htm
I want my TCO.
http://docs.activestate.com/activetcl/8.6/tcl/TclCmd/tailcall.htm
I want my TCO.
closed account (EzwRko23)
Even if they did, the compiler would have a really hard time doing TCO in the cases, where destructors are involved. It would have to reorder instructions (call the destructor before the tail call), making sure it doesn't break anything. Possible, but hard.
If you use a C string, C structure, or array it will be optimizable, but harder to code. On the topic of gotos I wanted to ask whether the gurus of what is evil think: Which is most evil, gotos or exceptions. I saw this thread and decided to revive it rather than make a new thread with people saying things that have already been said.
EDIT: I say that exceptions are evil, because a function forces you to put a try/catch block around it, and it cannot check whether you have done this. In contrast, with setjmp/longjmp, a jmpbuf* can be NULL, indicating that I am NOT going to catch that exception, so don't even check for it.
EDIT: I say that exceptions are evil, because a function forces you to put a try/catch block around it, and it cannot check whether you have done this. In contrast, with setjmp/longjmp, a jmpbuf* can be NULL, indicating that I am NOT going to catch that exception, so don't even check for it.
Last edited on
Topic archived. No new replies allowed.
Pages: 12