Oxygen Basic
Programming => Problems & Solutions => Topic started by: Mike Lobanovsky on March 21, 2018, 08:10:39 AM
-
Charles,
Can I be absolutely sure that, when an unprototyped function expects a pointer to whatever argument, it is guaranteed to receive that pointer no matter what if I prepend my argument with an explicit @ or &?
Can I be equally sure that, if I prepend my string argument with an explicit (albeit redundant) @ or &, O2 isn't going to choke attempting double redirection rather than single?
Can I be also sure O2 would resolve my explicit @ or & correctly when passing, as unprototyped arguments, the addresses of procedure entry points (including those in the DLLs currently mapped in the process memory), UDT members (even when inside a With/End With block), and array elements?
TIA
-
To keep the rules simple:
Use @ explicitly when passing numeric primitives, their arrays, and procedures byref. Indirection is correctly resolved
Use strptr for all types of string passed byval . This is optional but more efficient.
UDTs and class objects (passed byref) do not require @, but you may do so for clarity.
Use @@ for Virtual objects passed byref
-
Seems OK but still, can I use @/& instead of strptr, and if not, then why? Why still make a distinction if @/& are already near universal? (hint: Occam's razor)
-
You must use strptr to cover all string types, but @ will work for char and char*.
For string and bstring, I will see whether Occam's razor should be applied.
-
Thanks Charles, I can't wait to hear out your verdict.
-
Charles
is my next example correct
'autodefined pointers works
string a = "Oxygen"
@p = a
print p ' show Oxygen
char c[] = "Basic"
p = strptr c
print p ' show Basic
'defined not
sys p2
string a = "Oxygen2"
@p2 = a
print p2 ' show Oxygen
sys pc
char c[] = "Basic2"
pc = strptr c
print pc
-
string s="oxygen"
sys p=strptr s
char*c=p
print c 'oxygen
print @c 'equals p
-
Charles,
I assume the above is addressed to Aurel.
All that's left that I need to know is if this:string m = "World!", t = "Hello"
#ifdef _WIN64
! MessageBoxW Lib "User32.dll"
MessageBoxW 0, @m, @t, 0 ' OK I know it's redundant but still...
#elif defined(_WIN32)
! MessageBoxA Lib "User32.dll"
MessageBoxA 0, @m, @t, 0 ' Ditto
#endifcan produce the desired x86 and x64 effect now or at some definite future point in time.
TIA
-
Mike,
Yes in principle, except:
I dropped #elif if favour of #elseif
The RTLs have flags: mode64bit and mode32bit
You will require wide strings for MessageBoxW
wstring ws=s 'this will autoconvert
Unlike C, the o2 metalanguage is not preprocessed, and can be used inside macros which are also late-expanding. The differences are subtle but important for the coherence of the metalanguage.
-
!!! EXCELLENT !!! YOU ARE DA MAN !!! 8) :D
-
Aha! I see you slipped in those '@' pointers for dynamic strings instead of strptr. I will have to consult the dream council to get a final ruling..
-
Actually I didn't "slip" them "in", Charles. They've been there from the very beginning. You can see there were no later edits in my message. :)
Yes, I consider @ as a significant improvement over strptr from my perspective on how a practical intellisense system could be implemented in a hypothetical header-less O2 IDE to match Oxygen's unprototyped mode of operation.
And I'll be keeping my fingers crossed in the hope that every Z member in your z-Z-Z dream council will support a favorable verdict. :)
-
The dream council advises that we must maintain the current functionality of the '@' operator, since it is required for managing dynamic structures, such as strings of strings.
However, strings passed byval as unprototyped parameters behave impeccably, without requiring any explicit operator. (there are a few issues with variadic functions, but these follow a different route.)
So my best advice is to pass the strings directly :)
-
All right, Charles,
What will be, will be. :-\
-
Mike,
The only time you will need '@' is when passing numeric primitives and their arrays byref :)
Variadic functions are now fixed, and use similar rules.
https://github.com/Charles-Pegge/OxygenBasic
-
Charles,
I knew it! I said you're DA man! 8)
Thank you, that'll be pretty much enough to implement what I have in mind. Allow me some time to find my way around the competitor's environment. ;)
-
Variadic functions are now fixed, and use similar rules.
Is this fix transparent to DLLC? SB uses variadic functions/subs exclusively.
-
Yes, this is a minor fix, and DLLC doesn't use compile-level variadic functions. Their use is quite limited. Functions like printf and scanf require this feature.