Documentation

I don't know how I have to explain it to John: IT IS NOT A DOCUMENTATION PROJECT. They are draft pages in which I have been collecting information for personal use using markdown instead of a notebook. I don't know what I'm missing and I also don't know if all of what I have collected is correct. The redaction should also be modified because I have cut and pasted information from several sources: Microsoft, FreeBasic and PowerBasic. This can be acceptable for a draft, but not for formal documentation. I can't write anything of value about assembler and macros, and classes are going to change. Is that clear?

If anybody wants to use the draft pages for anything, he is welcome. I'm not in charge of the documentation. If I will do something with O2, I will do it at my own pace. I don't like to be pushed. It irritates me.

BTW, what have done you with O2 during that month, John?

[JRS]

Always good to know where you stand on things. I hope you find the magic in O2 someday like I did.

[Arnold]

Hi José,

your documents are already very helpful at this time and we should be very grateful that you took the time to do this. They help figure out the similarities and differences to other programming languages, and I think they also help Charles to develop new ideas. Your and Mike's contributions are always worth thinking about.

Roland

[JRS]

Well said Roland. José is an amazing talent and a good person others should try to emulate. Charles will always be the wizard that comes through when others say it's impossible.

[JRS]

José,

It seems your O2 repository is editable and allows deleting of pages. Are you sure that is what you want to do?

I'm not going to take the burden of maintaining the documentation. How I'm going to do a good job documenting a language that I still don't know? As I said, these are draft pages for personal use.

Today, I have modified a page to add this information found in a post of Charles in the "Custom Controls in OxygenBasic" thread:

there are 2 forms of at

mytype v at p 'direct coupling to pointer p
if p changes then so does @v

mytype v at (p) 'the address is the value of the expression (p)
@v is independent of p thereafter

How many things I'm still missing?

You want to drag me to a project about which I still have doubts.

[JRS]

No problem. I can change the URL to All BASIC for GitLab CE.

Charles,

The GitLab CE account you setup is active and ready for your use. The only difference is the URL.

https://sandbox.allbasic.info

Feel free to play in your sandbox as you see fit. (public / private repos)

Bonus, it's loaded with toys. 

[Charles Pegge]

Thanks, John. I'll take a look but for now, I have zero time-slots.

[Charles Pegge]

José,

I will endeavour to draw your attention to any technical aspects which differ from PB/FB.

While we are discussing pointers, the '*'  operator is occasionally used directly for dereferencing. It's default type is 'sys' but it may be cast.

Code: [Select]

int a
int b = @a
a=0x1234
print hex *b
print hex cast byte *b '34

PS:
I'm currently working on unsigned quads. It's  more tricky than anticipated (for 32bit binaries). I think they should be called qwords.

[José Roca]

Anybody that has used pointers with another basic dialect will try to write that code as:

Code: [Select]

dim a as long
dim b as long ptr = @a
a = &h1234
print hex(*b)

But unless you use the #cpointer on directive, it won't work. And what is worse, you won't know why because the compiler doesn't give any error.

I'm very picky with error checking, but assembler guys apparently not.

[Arnold]

If I recall this correctly then with my 32-bit Vista computer the OS would have crashed officially with a message if I had used: dim b as long ptr = @a or: long *b = @a. Now with my 64-bit system the app only terminates silently. This is indeed a bit problematic. I can only see this happen when co2.exe disappears from my task manager.

The directive #cpointer seems to offer some hidden extra features?

[José Roca]

This works without #cpointer:

Code: [Select]

dim a as long
dim b as long = @a
a = &h1234
print hex(*b)

but this does not:

Code: [Select]

dim a as long
dim b as long ptr = @a
a = &h1234
print hex(*b)

Assigning a pointer to a variable that has been declared as long

dim b as long = @a

and then deferencig it with *

print hex(*b)

goes against all that we have learned.

> The directive #cpointer seems to offer some hidden extra features?

It allows to use pointers as we are used to.

[Charles Pegge]

In Basic, parameters passed to a function by reference, are really pointered variables. But you never need pointer syntax to use them. You just handle them like any other variable.

This is the rationale for not using pointers explicitly. It produces cleaner code.

the #cpointer switch is only there to support C header #define macros. It won't work directly on pointer members.


A few ways to dim  pointered variables:

Code: [Select]

dim byref a, byref b as single
dim as single byref a, byref b
single ptr a, ptr b
single *a,*b

PS:
This works:

Code: [Select]

dim a as long
dim b as long ptr : @b = @a 'coupling by address
a = &h1234
print hex(b)


[José Roca]

the #cpointer switch is only there to support C header #define macros. It won't work directly on pointer members.

Then why this code works?

Code: [Select]

#cpointer on
dim a as long
dim b as long ptr = @a
a = &h1234
print hex(*b)


[Charles Pegge]

I mean pointer members expressed with ->

a->b

I'm reviewing the situation, but o2 currently relies entirely on the type definition to resolve indirect (pointer) members.

'@' is the same as '&' and is still recognised in #cpointer mode, so your example still works.

#cpointer can be turned on and off as required, but I hope that its use will be rare.