Hi Alan, I too come from a school where all declarations are put at the top of a program unit, but it seems more and more "fashionable" to restrict the scope of variables as much as possible, in this case the variables s and p. The code in csa.c is full of that type of local declarations.
I will try and get some information on possible performance impacts, but a friend already informed me that compilers are very likely to take care of that automatically. Regards, Arjen On 2012-02-19 19:01, Alan W. Irwin wrote: > On 2012-02-19 11:31-0000 arjenmar...@users.sourceforge.net wrote: > >> Revision: 12170 >> http://plplot.svn.sourceforge.net/plplot/?rev=12170&view=rev >> Author: arjenmarkus >> Date: 2012-02-19 11:31:08 +0000 (Sun, 19 Feb 2012) >> Log Message: >> ----------- >> Change the local declaration of "square* s" - the original was not >> accepted by MS VC/C++. > > Hi Arjen: > > The new declaration location is still inside two for loops so doesn't > that mean at run time the memory required for s is put on the > stack/removed from the stack (a->ni)*(a->nj) times, i.e., the number > of iterations of the inner loop times the number of iterations of the > outer loop? For large a->ni and a->nj this could become a run-time > efficiency concern. > > In other words, isn't this an example of the general case of a > statement that should be be moved outside a loop (or loops) since it > doesn't depend on anything happening within the loop? I suppose a > good optimizing compiler would effectively move all such statements > outside of loops, but I never completely trust such optimizations. (I > still vividly remember the case of the IBM fortran compiler in the > 70's that calmly removed statements that _did_ depend on the loop > outside of the loop when you told it to "optimize". So the programmer > lore then was to never ever use the optimizer for that compiler, and > it took IBM years to fix that bug.) In any case, I think it is simply > a matter of good programming practice to place statements in the right > location outside a loop or loops whenever we notice (as now) such > statements don't depend on anything in the loop. > > I know this code was not your original responsibility, but since your > change to separate the declaration from the assignment has made a > further efficiency change possible, I think we should do that (and > also in any other case where we have an obvious case of a statement in > a loop that depends on nothing in the loop). > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
