Thank you Hannes!
Ron? Do you have more info on this or is all told here? :)

Patrick

On Sun, Nov 16, 2008 at 3:02 AM, <[EMAIL PROTECTED]> wrote:

> Hi Patrick,
>
> > In the "old" Clipper days we where told to NOT overuse PUBLIC or PRIVATE
> > variables because they consume lots of memory and are slow. How is this
> in
> > xHarbour? Is this still true?
>
> I'd say, yes, because I don't think that xHarbour has changed the nature of
> PRIVATE and PUBLIC variables. Both are so called "dynamic variables" which
> are created at runtime, i.e. a symbol table holding symbolic names and
> values of these variables must be built at runtime.
>
> Lexical variables, like LOCAL and STATIC, are resolved at compile time.
> They
> are faster than dynamic variables, since the compiler can resolve their
> values to plain memory addresses. As a result, the lookup of values of
> lexical variables doesn't need a symbolic name table.
>
> > And, is a PUBLIC var more 'expensieve' than a PRIVATE var?
>
> No, both are equally expensive. The difference is that PUBLIC and PRIVATE
> variables are held in different symbol tables, as I assume. (Ron?)
>
> > Is it less 'expensive;' to have ONE public var with an array of lets say
> > 100
> > elements or 100 separate public var's?
>
> Depends on how you define 'expensive'.
>
> When you want to reduce the size of the symbol table for PUBLIC variables,
> you go with one public variable holding an array of 100 elements. Drawback
> is speed: accessing an array element of a variable is slower than accessing
> the value stored in a variable (Memory optimization).
>
> When you want to reduce the access times to values held in memory, you go
> for 100 PUBLICs and grow the symbol table (Speed optimization).
>
> IMO, neither memory nor speed optimizations are limiting factors in today's
> application development. The question is, how to organize 100 or 10000
> different variables so that a programmer can address them; not during
> compile time or runtime, but during programming time.
>
> The optimal replacement for PUBLIC variables with xHarbour is IMO one
> GLOBAL
> variable holding a Hashtable that stores names/values of former PUBLIC
> variables.
>
> My 2cnts,
> --
> Hannes
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> xHarbour-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
xHarbour-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xharbour-developers

Reply via email to