On Mon, 03 Dec 2007, Mike Evans (Gmail) wrote:
> Przemek, 
> I can send you all the manual of xBase++. They have the best manual I've
> ever read and over there you can find a lot of information's As an example :
> SET DELETED on | OFF | <lToggle> 
> Scope: thread-local, current work space

Thank you for your proposition. I've already read some xbase++
documentation so I have some basic ideas about their choices.

> As for variables visibility :
> Visibility of variables in different threads 
> 
>   Visibility              Storage class    
> 
>   Visible in the process  PUBLIC           
>   (all threads)           STATIC           
>                                            
>   Visible in the thread   LOCAL            
>   (this Thread)           PRIVATE          
>                           FIELD            
> Variables declared as LOCAL or PRIVATE are only visible in the thread where
> the declaration occurred. The variables declared with PUBLIC or STATIC are
> visible in all threads of a process (application program). Field variables
> (FIELD) are visible in a work area of a work space. A work space is bound to
> a thread. Since work spaces can be moved between threads, field variables
> can become visible in different threads. At a given point in time, a field
> variable is visible only in one thread.

I've read it but it does not explain what happens in some situations.
F.e. I have some private variables and create new thread. Does the new
thread inherit them or not or maybe inherits their clones?
What happen if I'll declare new public variables after creating new
threads. Will they be visible in all threads or only in the new ones
created after public declaration.
What does happen with public variable when its declaration hides
some previously defined private one with the same name when programs
leave the function where the public variables were declared and later
when leave the function where the private one were declared?
To implement the above description XBASE++ authors had to drop
compatibility with Clipper in few places.
If possible then I would like to ask xbase++ users to make a small
test with the code below. It shows some anomalies and bugs in Clipper
memvar implementation and I would like to see how close to Clipper
is xbase++ in its memvar implementation. If some can compile and run
this code and send the results here then it will help me to decide
if it's worth to replicate xbase++ behavior.

best regards,
Przemek



/*** mvtest.prg ***/
proc main()
? VERSION(), OS(), DATE(), TIME()
?
? "1", type("P1"), type("P2"), type("P3"), type("P4")
init()
? "5", type("P1"), type("P2"), type("P3"), type("P4")
? "===="
CLEAR MEMORY
? "1", type("P1"), type("P2"), type("P3"), type("P4")
init(1)
? "5", type("P1"), type("P2"), type("P3"), type("P4")
? "===="
return

proc init(x)
memvar p1
private p1:=1
? "2", type("P1"), type("P2"), type("P3"), type("P4")
init2(x)
? "4", type("P1"), type("P2"), type("P3"), type("P4")
return

proc init2(x)
memvar p3
private p3:=1
init3(x)
? p3
return

proc init3(x)
memvar p1, p2, p3, p4
private p3:="[c]"
public p1:="a", p2:="b"
if x!=NIL
   x:=type("P4:='d'")
endif
? "3", type("P1"), type("P2"), type("P3"), type("P4")
return
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to