Is this statement right?

[hungnguyengia]

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:

declare function somefunc(byval data as somestruct ptr) as integer

p/s: FB stands for FreeBASIC.

[SpriggsySpriggs]

_Offset returns the pointer to the variable you are passing it. It works fine for external libraries. I work with it all the time without issue. If you have issues, please post code in a code block and I will assist.

[hungnguyengia]

How to translate this C function into QB64?

int       IupExecute(const char *filename, const char* parameters);

I think it's like this:

function IupExecute%(byval filename as _offset, byval parameters as _offset)

And call it like this:

fn$ = "file name"
pr$ = "pr1 pr2"

IupExecute(_offset(fn$), _offset(pr$))

On FreeBASIC, it's like this:

declare function IupExecute(byval filename as zstring ptr, byval parameters as zstring ptr) as integer

IupExecute("file name", "pr1 pr2")

There different is, we don't have to create two new variables just to be able to pass it to the function.

[SpriggsySpriggs]

@hungnguyengia If they are both strings then you can use strings as well. As for the function return, int translates to LONG. % is an INTEGER in QB64, which is 16 bits. Since int is 32 bits, we need LONG, which is an ampersand (&).

So

Code: C++: [Select]

1. int IupExecute(const char *filename, const char* parameters)

becomes

Code: QB64: [Select]

1. Function IupExecute&(filename As String, parameters As String)

My preference:

Code: QB64: [Select]

1. Function IupExecute&(ByVal filename As _Offset, ByVal parameters As _Offset)

Both should work just fine. It's mostly up to your own preference. Sometimes, it's better to have a mix of using the actual string and using an _Offset. Especially for NULL values. Play around with combinations and find one that best fits your environment. Sometimes you might have to null-terminate a string with CHR$(0) as well.

[hungnguyengia]

On FreeBASIC, I could do something like this:

Type GENERIC_PTR As Any Ptr

Dim i as GENERIC_PTR

Could I do something similar with QB64? Because when everything is _OFFSET the code is almost impossible to understand. Intensive use of comments help a bit but this naming trick could really improve the situation.

For example:

int somefunc(struct somestruct *data);

On QB64 it will be:

function somefunc&(byval data as _offset)

Who know what type is data? The only way to read comments.

But something like this really helps:

Type SomeStructPtr As _OFFSET

This is way easier to understand:

function somefunc&(byval data as SomeStructPtr)

[hungnguyengia]

Regarding NULL, what is the equivalent of C's NULL in QB64?

For example: how this C code translated to QB64?

IupOpen(NULL, NULL);

[SpriggsySpriggs]

@hungnguyengia I've been replying to you on Discord. You'll get much quicker responses there and it's easier for me to keep track of this as I'll see the notification.

In regards to IupOpen(NULL,NULL)

it would be

IupOpen(0,0)