glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Cleanups...


From: simon schuler
Subject: Re: [glob2-devel] Cleanups...
Date: Wed, 26 Jan 2005 14:54:15 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041229

Nuage wrote:

no it doesn't, the
   static unsigned int t=0,  r=0, s=0;
variables are only initialized with 0 when the function is executed the first time, from the on the variables keep their values. (static definition) I've attached a small prog that demonstrates the function. Just compile and run it and you will see that it does the same like the old code. For better readabilty the =0's could also be removed, but then you would have to make sure, that the resetgradients is false before you execute the function first. The benefit of this patch is not allways have to execute these loops, (the test if (!gradientUpdated[t][r][s]) was executed MAX_RESSOURCES*numberOfTeam times on average, and allways the counting variables of the loop had to be incremented and tested) and not have to use this array anymore (saving some memory)


ok, sorry, I didn't read it carefully enough.

Well, "static" variable must not be used. They are opposed to a good
object-oriented design. You still can make the same if you put them (t, r, s)
in the object. In such a case, they would need longer explicit names.
Like "teamScheludIterator", "ressourceSchedluIterator", "swimSchedulIterator",
or something similar.

About the speed: This will not provide any noticeable speed improvement.
The clarity of the code is much more imporant! (much much more). If you
think it's more clear with 3 integers, then we'll use it!

Can you make such a patch ?

Thank you!
Nuage


Just had one more thought about it: Wouldn't it be possible to have a Gradient Class, then have classes RessourcesGradients, ForbiddenGradients, ... which have a private Gradient array. Then the whole thing could be solved with RessourcesGradients::UpdateNextGradient() . For me this would be a real improvement of code readability. I think it would also make the gradient concept more clear and easyer to understand. Besides of this it would shrink the Map class a bit, by moving the gradient computation functions and the pathfind functions into the gradient class. for me there is clearly too much code in Map.cpp now.

Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]