- Reversing a Linked List using Recursion - 14 Updates
- "default constructor" - 1 Update
| Richard Damon <Richard@Damon-Family.org>: Jun 18 08:18PM -0400 On 6/18/17 4:05 PM, Jerry Stuckle wrote: > nice and can speed up the code as well as save resources. But too many > unrelated actions can change the situation and making the optimization > no longer possible. If the choice is to write readable code that directly implements the algorithm, making sure I do things so the compiler can perform a common optimization that has great impact on the performance, or changing the code to apply the optimization manually, and making it noticeably harder to read, I will chose the readable version, and perhaps include a note on the conditions that need to be met so the optimization is available. Tail recursion is a simple to see case, and you generally know if your compiler can do it, so if the tail recursive version is signifcantly cleaner than the equivalent iterative version, then it makes sense to design it in. Now, for THIS problem, the recursive solution is probably harder to understand than the iterative solution (maybe if the recursive algorithm was documented it might be clearer), and so maybe not the best, unless it was presented as a learning exercise (in which case all the arguments about efficiency are irrelevant), in which case, perhaps part of the exercise should be to write up documentation for the function explaining HOW it does its work. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 18 09:33PM -0400 On 6/18/2017 8:18 PM, Richard Damon wrote: > compiler can do it, so if the tail recursive version is signifcantly > cleaner than the equivalent iterative version, then it makes sense to > design it in. It is *NOT* always simple to see. It is *NOT* just the function - it is also the objects which are being used. And there is the problem - maybe you think it will optimize to iteration today. But there is absolutely *NO* guarantee that a change to the code for the objects being used won't change that. And if it does, you can have major problems unrelated to the changes that were made. > about efficiency are irrelevant), in which case, perhaps part of the > exercise should be to write up documentation for the function explaining > HOW it does its work. Possibly, possibly not. I always recommend coding for clarity. But I also recommend NOT depending on compiler optimizations for the code to work. This is a perfect example of what can happen when you do. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Robert Wessel <robertwessel2@yahoo.com>: Jun 18 09:22PM -0500 On Sun, 18 Jun 2017 05:18:33 -0700 (PDT), >One shouldn't rely on compiler optimizations to ensure code correctness. Rather than using recursion write an explicit loop if there is likelihood of lots of iterations. Certainly not for a language like C or C++ where there is no guarantee that the compiler does anything like tail recursion. OTOH, a number of languages mandate tail-recursion optimization under certain conditions, and it's entirely normal to express (some) functions in a way that depends on that. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 19 01:58PM +0100 On Sun, 18 Jun 2017 17:55:59 -0400 Jerry Stuckle <jstucklex@attglobal.net> wrote: [snip] > I didn't say anything about manually optimizing the code. What I said > was if you need an iterative solution, write an iterative solution. > Don't depend on the compiler to optimize it. I think the problem may be that you express yourself poorly (or alternatively you have changed the argument). The original exchange which prompted this now lengthy "I'll argue to the death" discussion was that: * In response to a poster who said "it's important to write such functions so any recursive call is a tail call", you said "Whether it is head, middle or tail recursion makes little difference in the amount of memory consumed", * That poster was right and you were wrong. As I pointed out the key to the issue with gcc and clang is to avoid having objects in function scope with non-trivial destructors, in order to keep the recursive calls as tail calls which can be optimized. This has morphed into your proposition that you should not rely on optimizations of this kind, because you can subsequently inadvertently modify (or add to) the objects in function scope so that one of them acquires a non-trivial destructor. That is a separate matter on which you are on stronger ground. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 19 09:30AM -0400 On 6/19/2017 8:58 AM, Chris Vine wrote: > modify (or add to) the objects in function scope so that one of them > acquires a non-trivial destructor. That is a separate matter on which > you are on stronger ground. No, I was not wrong. And I am being very clear in my statements. But you seem to choose to pick bits and pieces instead of understanding the entire subject. Under very specific conditions, a tail call *MAY* be optimized into an iterative solution. However, any change in those conditions may change that - and the solution is no longer iterative. A tail call can *NOT* always be optimized to an iterative solution, and one should *NEVER* depend on that optimization. Even things like a change to the destructor of an object being used in the routine may change the result to a non-iterative solution. And when that happens, there is no change in the amount of memory consumed by the tail recursion vs. other recursions. Additionally, the C++ standard does not require this optimization, so a change in compilers (or even a change in the version if the compiler you are using) can change the optimization, making it non-iterative. The bottom line here is - although the compiler *MAY* optimize the code, which results in memory savings (or speed or other something else). But that should *NOT* be a design consideration for your program. Relying on a specific optimization for your code to work is just a bug waiting to appear. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 19 06:07PM +0200 On 19-Jun-17 3:30 PM, Jerry Stuckle wrote: > that should *NOT* be a design consideration for your program. Relying > on a specific optimization for your code to work is just a bug waiting > to appear. It's possible you guys are in violent agreement, heh. :) Cheers & hth., - Alf |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 19 05:11PM +0100 On Mon, 19 Jun 2017 09:30:03 -0400 > else). But that should *NOT* be a design consideration for your > program. Relying on a specific optimization for your code to work is > just a bug waiting to appear. Since you are just repeating the points you have already made on your second (different) point - that you should not rely on optimizations such as tail call elimination - it seems best to end this by concluding that you express yourself poorly on occasions, of which the posting to which I have referred is one. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 19 02:38PM -0400 On 6/19/2017 12:11 PM, Chris Vine wrote: > such as tail call elimination - it seems best to end this by concluding > that you express yourself poorly on occasions, of which the posting to > which I have referred is one. Yes, and since I have to keep repeating the same points I have already made, it seems best to end this by concluding that you have a problem understanding plain English. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 19 08:14PM +0100 On Mon, 19 Jun 2017 14:38:15 -0400 > On 6/19/2017 12:11 PM, Chris Vine wrote: [snip] > Yes, and since I have to keep repeating the same points I have > already made, it seems best to end this by concluding that you have > a problem understanding plain English. A weak response: you were doing OK but you have now let yourself down. I don't think you are claiming a divine mandate along the lines of Brian (http://comp.lang.cpp.narkive.com/q0Yuq9Cf/comments-on-interview-of-scott-meyers) with whatever vicarious perfection comes with it. Assuming that's right for you, expressing oneself poorly on occasions comes with the territory. Get over it. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 19 03:46PM -0400 On 6/19/2017 3:14 PM, Chris Vine wrote: >> already made, it seems best to end this by concluding that you have >> a problem understanding plain English. > A weak response: you were doing OK but you have now let yourself down. The truth hurts, doesn't it? But you'd never admit you have a problem with basic understanding. Others with whom I have discussed this and similar topics of the years don't have that problem. You seem to be a majority of one. > with whatever vicarious perfection comes with it. Assuming that's > right for you, expressing oneself poorly on occasions comes with the > territory. Get over it. Nope, but I am claiming I explained things as you could find in "C for Dummies". Too bad you can't understand it. Get over it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 19 08:50PM +0100 On Mon, 19 Jun 2017 15:46:13 -0400 > with basic understanding. Others with whom I have discussed this and > similar topics of the years don't have that problem. You seem to be a > majority of one. A majority of one? I don' think so. Most of your "discussions" end similarly. You let yourself down at the end. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 19 05:44PM -0400 On 6/19/2017 3:50 PM, Chris Vine wrote: >> majority of one. > A majority of one? I don' think so. Most of your "discussions" end > similarly. You let yourself down at the end. ROFLMAO! Lusers always try to blame the messenger. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 19 10:58PM +0100 On Mon, 19 Jun 2017 17:44:15 -0400 > > A majority of one? I don' think so. Most of your "discussions" end > > similarly. You let yourself down at the end. > ROFLMAO! Lusers always try to blame the messenger. Quod erat demonstrandum |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 19 06:13PM -0400 On 6/19/2017 5:58 PM, Chris Vine wrote: >>> similarly. You let yourself down at the end. >> ROFLMAO! Lusers always try to blame the messenger. > Quod erat demonstrandum Yup, you're one of the biggest lusers here, Chris. And your lack of understanding of simple concepts (not just this one) proves it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 19 01:49AM Newsgroups: comp.lang.java.programmer,comp.lang.c++ A default constructor is a constructor that misses something. In C++, it is a constructor that can be called with missing arguments (no arguments). C++ 12.1p4: A default constructor for a class X is a constructor of class X for which each parameter that is not a function parameter pack has a default argument (including the case of a constructor with no parameters). In Java, it is a constructor that is generated when an explicit constructor declaration is missing. The generated constructor just so happens to have no parameters, but an explicitly declared constructor with no parameters is not a default constructor, but replaces it: JLS8 13.4.12 Adding one or more constructor declarations to the source code of such a class will prevent this default constructor from being implicitly declared, effectively deleting a constructor, unless one of the new constructors also has no parameters, thus replacing the default constructor. Summary (simplified): In C++, "default constructor" means "any constructor that does not require an argument". In Java, it means "the constructor that is generated if the user does not declare any constructor". Newsgroups: comp.lang.java.programmer,comp.lang.c++ |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment