That's easily fixed by using CDECL to declare the functions.
Code:
Declare Function ThisIsMyFunction CDECL Alias "ThisIsMyFunction" Lib "thisIsMyLib.dll" () As Bungholio
Quote:Yeah, arguments were not checked if they were passed by reference, FB was converting anything to temp vars, new version won't allow that, (a) is a byref integer arg, while you are passing a byte var, new version will report:
test.bas(10) : error 59: Type mismatch, at parameter: 1
So or you redeclare it as (byval a as integer) or (a as byte).
New version does loads of parameter checkings that weren't done before, i was checking stuff at the Intermediate Representation module, what is a bad place to do that.. all checks done at the AST now.
New release will be done soon..
I'm kinda confused... Will we be bale to pass args like this?
Code:
DEFINT A-Z
declare Sub addone(NewA() as Integer)
type mytypeT
a(0 to 3) as Integer
end type
dim mytype(1 to 100) as mytypeT
for i = 1 to 5
addone mytype(i).a()
next i
For i = 1 to 5
For id=0 to 3
Print MyType(i).a(id)
Next
Next
sleep
SUB addone(NewA() as Integer)
For id = 0 to 3
NewA(id)= 1 + Int(rnd*10)
next
end SUB
Quote:That's easily fixed by using CDECL to declare the functions.
Code:
Declare Function ThisIsMyFunction CDECL Alias "ThisIsMyFunction" Lib "thisIsMyLib.dll" () As Bungholio
hrm, tried that, still failed with the same error. :\
zlib seems to use STDCALL on Windows, but the symbols on the DLL end up with CDECL names (no @), i dunno.
New version got the put/get #f, , array(), will store/load the full array, as in VB -- you can't use just "array" tho.
Dr_Davenstein: you can't pass array fields by descriptor currently, it's on TODO list.. since the 1st release, heh.. that needs temp descriptors.. argh
2 bugs:
1.fbc compiles
Code:
IF 1 = 1 THEN PRINT 1 ELSE PRINT 2
but exits on
Code:
IF 1 = 1 THEN END ELSE PRINT 2
with "error 3: Expected End-of-Line, found: 'END'". The later is accepted by qb.
2.fbc thinks "def seg" is wrong, but qb says
Quote:DEF SEG [=address]
If all arguments are omitted, the BASIC data segment is used.
which is the "BASIC data segment" in fbc if I have to apply it?
But I think it would be good to let fbc behave like qb
BTW:
http://www.fomalhautsoft.narod.ru/download/power.zip is a good puzzle game in qb, but it will not be compiled in fbc due to bug 2
FB has no segments, just remove the line and use varptr.
Also, you can't peek/poke directly to the videosegment, or use any other DOS specific hack.
EDIT: Haha, noone can beat The Z!re!, In your face Dr. D, in your face!
The second one isn't really a bug...
Code:
*****************************************************************************
* Unsupported (won't be implemented unless someone else does that...) *
*****************************************************************************
DEF SEG Statement (reason: segments are not needed in 32-bit flat mode)
ARGHHH!!! Beaten by The Z!re!!!
I wonder when people are going to start reading the documentation before asking redundant questions that are already answered in it...
Never. That's why the RTFM expression is so popular.
Which manual do you refer to? I never find a useful manual within the latest fbc release, not to say an up-to-date manual. Do you all surf the internet for document while programming? I suggest to put documents on
http://fbc.sourceforge.net/about.php into the zippd file- even if they are lack of update.
Another topic. Here is a code segment
Code:
a$ = "hello" + CHR$(0) + "world"
PRINT "a$="; a$, "len(a$)="; LEN(a$)
b$ = LEFT$(a$, 5) + RIGHT$(a$, 5)
PRINT "b$="; b$, "len(b$)="; LEN(b$)
PRINT LEN("hello")
TYPE u
q AS INTEGER
w AS STRING * 5
END TYPE
DIM r AS u
PRINT "len of type u="; LEN(u)
PRINT "len of r="; LEN(r)
qb gives
Quote:a$=hello world len(a$)= 11
b$=helloworld len(b$)= 10
5
len of type u= 4 <- why is it 4 other than 7?
len of r= 7
so guess what does fbc say?
I find
Quote:FB: Real length is the given len plus one (null-char), even on TYPE fields
Strings are filled with nulls (char 0), so strings can't contain chr$(0) chars
on
http://fbc.sourceforge.net/about.php?section=diffs. so is the answer
Quote:a$=hello len(a$)= 6 <- given len+1=6, well perhaps your answer is 5
b$=hellohello len(b$)= 10
5
len of type u= ?? <- I can not think it out.
len of r= 10
?
No! The real answer is
Quote:a$=hello len(a$)= 11
b$=helloworld len(b$)= 10
5
len of type u= 12
len of r= 10 <- 4+5+len of padding 0?
the "hello" on 1st line meets "strings can't contain chr$(0) chars", but len(a$) and the 2nd line say that it is wrong.
First, is there anyone can explain what does LEN(UDT) mean in QB and fbc, and why is LEN(UDT) not equal to LEN(UDT var), (in C, sizeof(UDT)==sizeof(UDT var), right?) ?
No, please do not misunderstand me and do not fix the LEN function. I do not like the way that C treates string( chr$(0) is only used to end a string), so can you let fbc be more Qb-ish by fixing PRINT, and fix LEN on UDT and UDT-var for the Qb-ish reason and consistant reason( len(integer)=4 in fbc)?
thank you.