quote:Original post by Sneftel
Yes it is,
quote:because C++ is side-effect-happy. If C++ could do garbage collection, the example I cited would tail-recurse just fine.
quote:Original post by DrPizzaNo, it''s just GC. Finalizers don''t affect tail-recursion at all if their invocation doesn''t have to be at a particular line in the code; dependencies further down the stack will keep objects alive as long as they''re needed, and the GC will destroy them afterward.
The issue isn''t just GC; it''s the existance of destructors/finalizers. But, again, this isn''t unique to C++.
quote:Finalizers don''t affect tail-recursion at all if their invocation doesn''t have to be at a particular line in the code
quote:Original post by DrPizzaWhich is yet another example of C++''s feature set hindering this optimization. Languages with lazy or asynchronous GC prohibit programmers from expecting finalizers to run immediately, thus freeing up the compiler/interpreter to run them whenever is most convenient. By rigorously specifying object destruction time, in contrast, C++ limits itself to control flows that can properly respect these specifications.
"if". So, like I said, it''s not just GC. If your destructor did something such as print a message to the console to indicate that it was being destroyed (that whole "side-effects" thing again) then you''d still need to maintain a stack of the objects to be destroyed, so that the messages can be printed to the console in the correct order.
quote:Original post by DrPizza
It isn''t possible to eliminate them all (not least because C++ has no other way of performing I/O), but I certainly don''t use assignments often.
