* bin/check.hb
* config/*/*.mk
* contrib/gtwvg/wvgwing.c
* contrib/hbcomm/comm.prg
* contrib/hbfbird/tfirebrd.prg
* contrib/hbfimage/fi_wrp.c
* contrib/hbformat/hbfmtcls.prg
* contrib/hbformat/utils/hbformat.prg
* contrib/hbhttpd/core.prg
* contrib/hbnetio/utils/hbnetio/hbnetio.prg
* contrib/hbnetio/utils/hbnetio/netiomgm.hb
* contrib/hbsqlit3/hdbc.prg
* contrib/hbwin/win_bmp.c
* contrib/xhb/htmutil.prg
* contrib/xhb/thtm.prg
* contrib/xhb/xhbarr.c
* contrib/xhb/xhbtedit.prg
* ChangeLog.txt
* debian/control
* debian/copyright
* doc/*.txt
* LICENSE.txt
* package/harbour.spec
* README.md
* src/compiler/hbusage.c
* src/pp/hbpp.c
* src/rtl/memoedit.prg
* src/rtl/teditor.prg
* src/rtl/tget.prg
* src/rtl/version.c
* utils/hbi18n/hbi18n.prg
* utils/hbmk2/hbmk2.prg
* utils/hbmk2/po/hbmk2.hu.po
* utils/hbtest/hbtest.prg
* sync with 3.4 fork (no change in functionality)
CC3 -> CC4 license, copyright banners, some strings, minor
code changes, doc folder, TOFIX -> FIXME
50 lines
2.1 KiB
Plaintext
50 lines
2.1 KiB
Plaintext
I just started implementing Classes and objects creation when I realized
|
|
Harbour is not managing static variables yet (Harbour recognizes them but
|
|
does not generate the proper pcode for them).
|
|
|
|
So I would like to make an introduction to static variables management as
|
|
it is a sophisticated system that Harbour is going to implement.
|
|
|
|
It is something publicly known that Clipper static variables are
|
|
located at the bottom of the data segment. This has caused all kinds of
|
|
troubles. This is why when I designed Five I did it in a way that could not
|
|
cause any trouble in the future.
|
|
|
|
In Harbour all static variables (and I mean on all PRGs) are stored in
|
|
just one Harbour array (a Clipper language array), this guarantees that we
|
|
may have as many static variables as desired without limits (just limited
|
|
by the available memory). This aStatics array is not visible from the
|
|
application (PRG level).
|
|
|
|
Basically what happens when a function is called and that function uses
|
|
static variables, is that the stack sets a pointer to that array section
|
|
where our statics are, so from that moment on, accessing a static1, static2,
|
|
... is accessing some elements on that array:
|
|
|
|
static1 = statics[ statics_base_for_this_function + 1 ]
|
|
|
|
...
|
|
|
|
staticn = statics[ statics_base_for_this_function + n ]
|
|
|
|
In order to implement this we just use two new pcode opcodes: _STATICS,
|
|
_SFRAME. _STATICS makes the global statics array grow enough to hold our new
|
|
defined statics:
|
|
|
|
_STATICS <n> --> ASize( aStatics, Len( aStatics ) + <n> )
|
|
|
|
_SFRAME --> tell the stack from what location into aStatics are ours.
|
|
|
|
_STATICS is just called once for an entire PRG from an init function
|
|
named _INITSTATICS (STATICS$ and SINIT in Clipper). That function stores in
|
|
a tricky place (its own function pointer in the symbol table!) our statics
|
|
base, and later on _SFRAME simply takes it from there and sets it in the
|
|
stack. That _INITSTATICS function will perform whatever initialization our
|
|
global statics may have defined in that PRG).
|
|
|
|
You are going to see the code for all these. I just wanted to provide a
|
|
clear idea about how Harbour does its magic :-)
|
|
|
|
|
|
Antonio
|