What is the relationship between FreeBASIC, ThinBASIC and OxygenBASIC?

[hungnguyengia]

The more I researched about Xojo the more I like it. But given it prices it's unaffordable for me. So I go away from commerical BASIC and have some fun with Yabasic.

[hungnguyengia]

I liked Gambas, too. But it's almost locked in Linux. I really liked the syntax but I will not install Cygwin on Windows just to have it up and running.

[aurelVZAB]

@hung
use Arturo :D

[Lost Zergling]

Just to clarify, I do not promote 'spagueti' programming. I'm convinced object design is in general best, despite I personnally use structured programming most. I'm eclectic : in lzle, I'm using types to make the link with object interface via properties. Almost everything could be designed using object design. When one try to really challenge object design, you need to short circuit high level paradigm, ie : functionnal programming (object on low level hardware (stack) and same time some new approach on high level paradigms), not just low level optimization. I would rather believe in an 'hybrid' technology meaning multi paradigm : object design would be important part of the core, nevertheless it could be strenghten or completed by dedicated instruction set extensions (biding). Sorry for sometimes not being serious, I think this is my way.

[hungnguyengia]

@hung
i dont get it you said you leave Windows and runing Linux ...now you use Windows ???
because FreeBasic run on both why dont start using it,,there are lot of programs ,games libs examples...etc

Different machine. Laptop with Windows and desktop with Linux. FreeBASIC is of course fine. But I'm exploring the BASIC world.

[hungnguyengia]

I have some troubles with QB64. QB64 simply doesn't have typed pointer type, everything they have is just the _OFFSET type (it's a generic pointer holding an address in the memory) and _MEM (IMHO is just a fat pointer). Even though it could interop with C I find it's extremely difficult to translate C headers/using C libraries with QB64 than FreeBASIC.

[aurelVZAB]

For some reason i don't understanding you ..

[hungnguyengia]

For some reason i don't understanding you ..first UDT,now POINTER type
Only BASIC dialect as i know which have real pointer type is IonicWind Basic ...former Emergence Basic
32bit only , Oxygen basic also dont have pointer type but have generic types @

Now I don't understand you. I mean typed pointer type, not real pointer type. FreeBASIC definitely has typed pointer type.
For example:

dim sth as zstring ptr
dim sth2 as long ptr
dim sth3 as zstring ptr ptr

On QB64, we only have _OFFSET and _MEM.
Look at this example:

https://www.qb64.org/wiki/Windows_Libraries

As you see, they have to substitute any pointer types with the generic _OFFSET. This is real trouble when interfacing with C or even doing something useful with it own.

Look at this example:

int somefunc(struct somestruct *data);

Which translate to this in QB64:

function somefunc%(byval data as _OFFSET)

How we actually use this in code?

Instead of parse it directly like on FB, we have to create it first:

dim data as somestruct

data.somefield = somedata;
...

somefunc%(_OFFSET(data))

This is how we call it. Think about it. How inconvenient it is? It's also not type-safe as the generic pointer _OFFSET has no type and we have to workaround this by comment, intensive comments. Instead of a self explantory declaration on FB.

[hungnguyengia]

Here is more QB64 quirks. QB64's function doesn't have return type! One has to use type suffixes to specify which type the function returns:

https://www.qb64.org/wiki/FUNCTION

And here is type suffix list:

https://www.qb64.org/wiki/TYPE

This is extremely limited and it seems QB64's function can only returns primitive types! Of course one can workaround this using pointers but again on QB64 we only have the generic pointer _OFFSET but no typed pointers! This make writting code extremely error prone and inconvenient. The code itself is also very ugly.

[hungnguyengia]

Another problem is the generic pointer _OFFSET unlike C's void pointer can't be casted to other types! When interfacing with C library, one will have to deal with type mismatch compilation errors that really not easy to solve.

[aurelVZAB]

I am wondering now do you really need this in your programs ?
Pointers are good if you doing some really complex programs and as the word say

[hungnguyengia]

Lockdown is boring. I tried to port FreeBASIC's IUP headers into QB64. A lot of pointers! Sometimes pointer to pointer and to another pointer! The limitations of QB64 make me mad. The goal is having the IUP headers ported to QB64 and transform the source code of IUP_FB_EDITOR to be able to build with the QB64 compiler and ready for the fork IUP_QB_EDITOR. But now I'm consider to quit. Perhaps I'm overestimate myself and too careless not checking the capacity of QB64 before ever thinking about this!

[aurelVZAB]

Oh man translating includes like IUP is not easy and everyone can make a lot of bugs errors etc.

[caseih]

Here is more QB64 quirks. QB64's function doesn't have return type!

You do realize that QB64 is a portable implementation of 30-year old QuickBASIC, right? Why are you surprised it doesn't support things that QB also did not support and can't easily interface with the modern C library?

FB has all the features you apparently require, yet you keep on posting about everything but FB!

[aurelVZAB]

Yes i already told him that ..why not FB..