OpenEuphoria

Re: SQLite wrappers

• Posted by DB James <larch at adelphia.net> Aug 24, 2005
• 720 views

Tone Škoda wrote:
<SNIP>
> anyway i am going to do the wrappers for those additional functions and since
> c pointers
> are still blurry to me i made me this tutorial to clear them up:
> <a
> href="http://www10.brinkster.com/tskoda/C_pointers_explanation.htm">http://www10.brinkster.com/tskoda/C_pointers_explanation.htm</a>
> maybe someone will find it helpful.
> 

Hi Tone,

I glanced over your self-explanation of C pointers are, how they work, and why
they are confusing.  I agree there is something elusive about them and I've seen
C expressions that are as weird looking as the stranger propositions in
metaphysics: pointer variables to arrays of pointers, etc.

I wonder if, in the beginning of C, there had been "val", "adr", and "ind"
(indirect) keywords -- would that have helped?  Assuming a language called maybe
Explicit C, all references to variables had these terms, then probably there
would not be this confusion of memory-location and
value-contained-in-that-location.

if bar is in memory address 10 and that contains the number 20 and the value
stored in memory address 20 is 30, then

val foo = adr bar --foo now equals 10
val foo = val bar --foo now equals 20
val foo = ind bar --foo now equals 30

To load an offset, i.e. a memory location:
val count+=1
val foo = val (val bar + val count)

To load a value at an offset:
val count+=1
val foo = ind (val bar + val count)

To call a routine that expects a number:
MyProcedure(val normaJean)

To call a routine that expects an address:
x=MyFunction(adr marilyn)

So, all left-items are always just numbers, and in practice the "val" could be
left off.  What use there is in *var=whatever, I don't know.  It is still just a
number, like everything in computers.  My impression is that it is "typing" gone
wild, where not only the byte-length of a variable is declared, but the
interpretation of the numbers as well.

Just some idle musings...

--Quark