FreeBasic anomalies encountered by Moneo

[Moneo]

I picked one of my old programs specifically to do some FB testing. It's a date handling and calculating program with 710 lines of code. I've made very few changes to this 10 year old QuickBasic 4.5 program.
QUESTIONS:
- Is this the right place to post this kind of FB anomaly?
- Should I post each anomaly separately from now on?

ANOMALY #1: Coding line continuation.
This is a minor issue. Using FBIDE, and when I load (open) an existing program, it does not recognize a LINE CONTINUATION character of "_", causing an error 33 at compile time.
The QuickBasic manual says: If you use your own editor, you may use underscore as the last character to create a program line that extends across more than one physical line. When loading your program into the IDE, the underscores are removed and the continued lines are joined to form a single line.

ANOMALY #2: Passing parameters to function By Value
Please see the following code:

Code:

defint a-z
declare function Fillstring$ (v#, zl)
dim zyy as integer
.....
z$ = Fillstring$((zyy), 4)   '*** issues error 59 at compile time
.....
' Converts a value to string of specified length with leading zeros.
FUNCTION FillString$ (V#,ZL) STATIC
  FILLSTRING$=right$(STRING$(ZL,"0")+MID$(STR$(V#),2),ZL)
END FUNCTION

The line above which invokes the function, has parentheses around the variable zyy to indicate that it is passing this parameter BY VALUE. The compiler issues "error 59: Type mismatch, at parameter: 1"

ANOMALY #3: Modified STR$ handling.
n$="123"
print val(n$) ' This will print a space followed by 123. The space is an implied positive sign.

print str$(val(n$)) 'No matter how annoying, this historically will create a string with the val of n$, which is space and 123, convert this to a string with the same space and 123, and then print this.

The FB compiled version of str$(val(n$)) produces a string with only 123, that is, it dropped the leading blank produced by the val.
THIS HAS TO BE CONSIDERED A BUG. MANY, MANY PROGRAMS ARE EXPECTING THE LEADING BLANK.

Thanks.
*****

[v3cz0r]

1) Expanding _ would screw up the source-code, as the QB IDE loved to do, FBIDE is not a QB IDE clone

2) The ()'s trick with paramenters is not supported, you have BYVAL arguments, i won't hack my parser to add that bad work-around because M$ couldn't add proper BYVAL arguments before PDS

3) STR$ won't return blanks, i always hated to type LTRIM$( STR$( value ) ) all the time, while the blank is useful when printing, i see no reason to keep it for STR$ and it won't be changed, the compiler itself uses STR$ in many places and the blank is never considered

[keeling]

I use the underscore all the time for continuation... just make sure it is an underscore followed by a space.

Code:

PRINT _
     "Hi"

[adosorken]

Much of this has already been covered numerous times since FB's inception. None of it is anything new.

[Moneo]

1) Expanding _ would screw up the source-code, as the QB IDE loved to do, FBIDE is not a QB IDE clone

2) The ()'s trick with paramenters is not supported, you have BYVAL arguments, i won't hack my parser to add that bad work-around because M$ couldn't add proper BYVAL arguments before PDS

3) STR$ won't return blanks, i always hated to type LTRIM$( STR$( value ) ) all the time, while the blank is useful when printing, i see no reason to keep it for STR$ and it won't be changed, the compiler itself uses STR$ in many places and the blank is never considered

V3cz0r,

First let me say that you guys have done a fabulous job with FB. Please take my comments in a positive tone.

1) Since expanding _ is a minor issue, you can leave it as is.

2) The () is not a trick, it is explicitly documented in the QuickBasic manual in the section "Passing by Reference and Passing by Value".

3) Regarding the STR$ function, the QuickBasic manual says:
STR$(numeric-expresssion)
If numeric-expresssion is positive, the string returned by the STR$ function contains a leading blank.

Regarding 2) and 3) above, let me quote from www.freebasic.net:

"FreeBASIC - as the name suggests - is a free, open-source, 32-bit, MS-QuickBASIC's syntax-compatible compiler, that adds new features such as pointers, unsigned data types, inline-assembly and many others."

I interpret compatibility as just that, with documented dfferences of course. I have read docs/keywords.txt and changelog.txt, and have found no mention of the 2) and 3) issues above.

There are things that I too have always hated about Basic, but have learned to program around them, and they have become part of my style, as I'm sure they have for others.

I think that modifications to documented specifications of QuickBasic should be restricted to those that are absolutely necessary for the 32-bit and Windows environments.

Better ideas are always welcome as additional statements and functions to the language.
*****

[ShadowWolf]

Freebasic is a new basic dialect it not ment to clone QB just keep with the same syntex which it does very well.

the () trick really is microsoft using a hack it should have never been done like that most likely it was a last minet add on.


the STR$ isn't going to be changed since it not that big of a deal and victor like he said is using it in the compiler so changing it would mean rewritting the compiler to what acomindated a QB quirk.

QB as great as it was had some strange things going on in the language that freebasic thankfully cleaning up.


but i do think the keyword doc should have a (diff for the str$

[Moneo]

ShadowWolf,

Are you a member of the FreeBasic development team?

If so, your opinions will be held at a higher level of regard.
*****

[Antoni Gual]

Here is my list:

Code:

Porting QB apps
-----------------------
-Vars of  unspecified type are integer in FB, in QB they were single
-Integer and Long  are  both 32 bits,  if for a specific usage you need a 16 bits integer you need to define it  as SHORT.
-Cant’ use  type suffixes ($,%,&,!,#)  to distinguish variables with the same name or to convert a keyword into a variable. For example  a% and a! can’t coexist in the same program.  for%  is not accepted as a variable name.
-Type fields are aligned by default  in 4 bytes limits. If you use a TYPE to GET /PUT data from/to a file, you must use  TYPE <name> FIELD=1 to have FB aligning fields as QB.
-Fixed length strings used to retrieva data from a file with GET/PUT must be defined with the required length –1.
-SLEEP argument is in milliseconds, not in seconds as in QB .
-No CALL ABSOLUTE  allowed. 16bits machine code will not work. It must be translated to 32 bits assembler. FB allows inline assembler.
-FILES keyword does not exist., instead the more useful  DIR$ from PDS is implemented.
-FIELD was used for file access and is not implemented.  FB has a FIELD keyword to define the packing of the TYPES
-Old 16 bits assembler libraries can’t be used
   ffix, multikey,QBMIDI        
   DirectQB, Cosmo, Future, uGL
   DS4QB++,dsock                  
-COMMON does not need  /name/  clauses
-Strings in  DATA must be enclosed in  " ", QB only required it if strings had commas .
-CLEAR does not erase all variables and resizes stack.
-DATE$ sub is now SETDATE
-TIME$ sub is now SETTIME
-ENVIRON$ sub is now SETENVIRON
-ERR /ERROR  use differnt error numbers
-Functions and subs don’t allow the hack  bar ((foo)) to pass  a variable byvalue, byval must be used.
-FRE  Is still a garbage cleaner but returns always 0
-LSET X=Y must be written Lset X,Y  and does not take an expression as a second argument
-NAME old AS NEW must be written NAME old, new
-OPEN does not support com: scrn: keyb: lpt: , now suposts con: err:
-RND  optional argument <0 behaves as if 0
-RUN requires extension to be specified
-RESUME <label>  does not exist, you can still use  RESUME and RESUME NEXT
-Option -xe in compiler call is needed for  ON ERROR and  RESUME
-SHARED  keyword can’t be used inside functions and subs.
-No límits checking in  arrays, if you go beyond the end of an array anything can happen.
-Function and Sub DECLARES require parentheses  even if they don’t have arguments
-Strings are implemented using a C library, can’t contain the character ascii 0.
-Arrays were in qb QB  first index  first , in FB they are last index first.
STR$ does not add a blank at the left when the number is positiva.
The line continuation code is  underscore in QB, while in FB is space+underscore

NO IMPLEMENTED
-----------------
-No INP,OUT,WAIT  as 32bits OS’es do not give access to hardware ports. INP and OUT are implemented as aliases of  PALETTE so can still  be used to set the palette
-No built in Serial comms support, you must use an external library
-No SOUND, no PLAY, VARPTR$   only BEEP exists. Use an external library.
-No LPOS, LPRINT no built-in printer support.
-NO DEF SEG,VARSEG,as 32 bits processor do not use segments
-No CALL Interrupt as 32bits OS’es don’t use the Interrupt-style API
No QB- emulated events:
-No  ON TIMER, TIMER ON ,TIMER OFF
-ON key(n),key on ,key off,key
-NO on pen, pen off, pen on
-No play(n), on play
-ON sTRIG,stick  
-ON event, on uevent

No DEF FN. Use FUNCTION
No ERDEV, ERDEV$
No IOCTL, IOCTL$
No CVDMBF,CVSMBF,MKSMBF$,MKDMBF$ as they were used to convert floating point numbers to/from an old Microsoft format. If you need to deal with a file in that format, write a QB converter. FB uses IEEE764 floating point format, the same as the FPU of the processor.
-No ERL
-No FILEATTR

As you can see, FB is not a QB clone, it just can run QB programs with minor changes, probably less than PowerBasic would require.

[Z!re]

FRE isnt a garbage cleaner, it simply returns the amount of free memory.
Just like it did in QB.

Except, now it cant take any parameters.

[ShadowWolf]

ShadowWolf,

Are you a member of the FreeBasic development team?

If so, your opinions will be held at a higher level of regard.
*****

nope not part of the devoplement team.