[Gambas-user] static const?

[Doriano Blengino]

Fabián Flores Vadell ha scritto:
> 2010/4/13 Jussi Lahtinen<jussi.lahtinen at ...626...>:
>    
>>> Just in case:
>>>
>>> REPEAT
>>>      b = TabStrip3.Count ' In fact, this does nothing usefull
>>>      INC a
>>> UNTIL a<  TabStrip3.Count OR TabStrip3[a].Caption = IdCaption
>>>        
>>   This doesn't make same functionality.
>>      
I can't resist to add my mis-contribute...

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. 
The C language, in facts, does not even have CONSTs - it goes with 
#define. So, it would be correct to forbid STATIC when declaring CONSTs. 
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.

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. . 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).

Finally, your last lines of code do not work:
> 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
>    
Suppose you have a tabstrip with three tabs, and last, Tabstrip1[2] has 
the caption we want.
In the first cycle, we test Tabstrip1[0]: does not match, and "a" turns 1
In the secon cycle, we test tabstrip1[1]: does not match and "a" turns 2
The third cycle does not get executed - "a" is 2, which is not less than 
"3-1" (it is equal).

Moreover, your algorithm does a double test on caption, which could be 
avoided. 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?

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.

It seems to me that you have said that an exception would be the FOR 
EACH cycle... why?

Regards,
Doriano