2010/4/14 Doriano Blengino <doriano.bleng...@fastwebnet.it>: > Back to the beginning: a CONST declaration is something that uses no > memory, so it can not have instances, and hence it can not be STATIC.
> On the other hand, a CONST is always static, because the effective data > it describes reside in a memory outside the program - they reside in the > compiler memory. Thanks Doriano. I understand that. My question was caused by the fact that the compiler allows use the keyword STATIC in the declaration of constants, even though the online help and a very basic logical reasoning indicate that use the keyword STATIC is unnecesary in this situation > About the cycles WHILE, FOR, REPEAT and so on, I think the statements > BREAK and CONTINUE are very useful (I would add a third statement: > RESTART): they permit a finer control and many times they are clearer > than complex tests. You do not give arguments to support your opinion. Can you give me some examples? I think, that these can be obvious for you, but not for me. > Your example only has two test, against COUNT and > the CAPTION. What kind of test would you write if the conditions were > 15? Perhaps concatenated (I mean, some test are only meaningful when > other conditions are met). Assign the results of logical expressions to Boolean variables, it is often the way to manage the complexity of conditionals expressions. And in the loops, to use these variables instead of those logical expressions. But I think that you are knowing well this, and you points to the performance of programs. If so, my answer is that the performance isn't a priority in many types of programs, and the evaluation of logical expressions have a little cost in comparation with other operations (I/O, compression, among many others). > Finally, your last lines of code do not work: Yes, it works. >> PRIVATE FUNCTION ScanTab(IdCaption AS String) AS Byte >> DIM a AS Byte = 0 >> >> WHILE (a< TabStrip1.Count - 1) AND (TabStrip1[a].Text<> IdCaption) >> INC a >> WEND >> >> RETURN IF(TabStrip1[a].Caption = IdCaption, a, -1) >> END > The third cycle does not get executed - "a" is 2, which is not less than > "3-1" (it is equal). That's irrelevant because the external comprobation (the logical expression in the return sentence) > Moreover, your algorithm does a double test on caption, which could be > avoided. I think that the second test can't to be avoided. If it isn't put out the loop, you have to put into the loop. The reason for include the test (TabStrip1[a].Text<> IdCaption) in conditional expression is only stop the loop if there's match before get the last item. I think that this code can to write in many ways, but with no significant variations. How would you do? > Doing an additional test is not an important thing if the test > is quick and the routine is called not too much often. What if the > routine is called millions time, or the test is more heavy? I think that the computational cost of evaluate complex logical expressions, generally is insignificant. But if not, then the first thing to be considerated is the language to use, and I see few alternatives: assembler, C, C++, someone else; the second thing is the many optimizations to do. But, what kind the system would be? One that is not possible to do with Gambas. > About not using RETURN or BREAK inside cycles, we must think at > different kind of cycles. The WHILE and alike, where no variables are > directly involved in the cycle declaration, never have problems - the > semantic of the declaration does not imply anything about variable > allocation. In the FOR cycles instead, other languages can do strange > things, both on allocation and code optimization, so it is effectively a > bad idea to fiddle with the loop control variable; in other languages > this is not stressed the same way (basic, for example), but actually is, > at least, ugly. Yep, but I not was thinking in possible collateral effects, derived from implementation of language. (To those, the corresponding compiler would let in evidence, or would become a logical error isn't very difficult to detect and correct). I was thinking in conceptuals implications. This conceptuals implications derives in to use of the language resources in any ways, instead to use them in the correct situations. > It seems to me that you have said that an exception would be the FOR > EACH cycle... why? FOR EACH really iterates through all items, so there's only way to stop the loop when it's goal is achieved, is by the BREAK sentence used in a conditonal sentence inside the loop. But it might think that if it is necessary to do this, then the iterative structure FOR EACH is not adequate. And I hope that my very ugly english, does not cause tears. -- Fabián Flores Vadell www.speedbooksargentina.blogspot.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
