FreeBasic anomalies encountered by Moneo

[Moneo]

Here is my list:

Code:

Porting QB apps
-----------------------
-Vars of  unspecified type are integer ......

As you can see, FB is not a QB clone, it just can run QB programs with minor changes.........

Antoni, Thanks for sharing your informative list with us. I am saving it for reference.

I didn't expect FB to be a clone of QB, but I interpreted the term "compatibility" to be quite closer. The 710 line program that I mentioned, took me about 7 hours to get compiled and to work properly.

IMHO, modifying the STR$ to get rid of the leading space when the value is positive, just because someone hated the way QB does it, is not a valid reason. If you absolutely want it that way, then make a new function, like STRNS$, where NS means no space.

In FB, why does VAL keep the leading space?
Do a PRINT VAL("123") and you'll see the leading space.
This makes the STR$ and VAL functions in FB no longer the complement of each other.
*****

[Moneo]

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.

Ok, ShadowWolf, then I'll go back and read your previous comments and consider them as your opinion, to which you are entitled, just like me.
*****

[Z!re]

Hey, Moneo..

Nice attitude.

IMHO, modifying the STR$ to get rid of the leading space when the value is positive, just because someone hated the way QB does it, is not a valid reason. If you absolutely want it that way, then make a new function, like STRNS$, where NS means no space.

In FB, why does VAL keep the leading space?
Do a PRINT VAL("123") and you'll see the leading space.
This makes the STR$ and VAL functions in FB no longer the complement of each other.

STR$() Shouldnt return a space, it's un-needed, if you cant code around that or if it impacts your code so hugely as you make it out to do, well, then I feel sorry for you.

VAL() and STR$() are the complements of each other, try reading:

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

Code:

? 123
Print Val("123")
? Str$(123)
Print Str$(Val("123"))

But hey, what do I know.. I'm not an official member of the FB team..

Fsuck me for helping and replying with what I know and have learned over time, and by talking to v1c frequently.


If you only want v1c or official team members to post replies, then go to the sourceforge forum. Or even better, PM them, staff list:
v3cz0r: FB
lillo: FBGFX




Ok moneo, I'll go back and read your questions like you're a computer illiterate now.


EDIT: Spelling/code corrections


EDIT 2:

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

[Moneo]

Zire, I appreciate your trying to help.
*****

[Z!re]

NP, thats what the forum and it's members are really for.

[v3cz0r]

Syntax compatibility has nothing to do with the semantics, i could have chosen to use UNICODE for storing strings, or to store the UDT members in a completely non-standard way and the syntax would still exactly the same.

Some corrections:

-Cant’ use type suffixes ($,%,&,!,#) to distinguish variables with the same name

A!, A#, A%, and A$ are all valid with scalars and arrays, they are different symbols, you probably used an old version that had some problems with suffixes.

-Function and Sub DECLARES require parentheses even if they don’t have arguments

"declare sub abc" is valid as "declare sub abc ()", the later was obligatory in QB. That didn't change since the first version.

The line continuation code is underscore in QB, while in FB is space+underscore

"abc _" or "abc _ " are the same, no space has to be used after the underscore. Version 0.12 would not skip the comments after the line-continuation, but that was fixed ~2 months ago.


VAL() doesn't add any blanks as it returns a double value, it's PRINT that does for non-unsigned integers or floating-point numbers.

[Moneo]

Well, I can see I'm wasting my time (and yours) discussing my concerns regarding what I consider incompatibilities of FB with QB. Recently a member, I think from the development team, encouraged me to get into FB and do some testing using my experience.

It seems now that 36 years of having programmed in Basic doesn't mean anything. What counts now are the new decisions taken by those developing FB.

In the future, I'll try not to burden you with posts regarding further anomalies that I encounter. If you have a central gathering place for differences, please advise where and I'll send them there.

If I get stuck with a problem, then Í'll post for help.
*****

[Z!re]

Want a whip for that high horse of yours?

FreeBasic is NOT QB.

Get over it.


Stop insulting us.

[adosorken]

I have had zero problems coding in FB since day 1. It's as easy to code in FB as it is in any other BASIC...in fact, easier than many, such as VB.net. Of course, I only have 20.5 years of experience, so I guess that's not as much :roll: but regardless...yes, FB will go where its developers wish it to go. FB is the next step in BASIC's evolution. Quirks in other BASICs that have driven coders mad for years are simply gone, replaced by more efficient and sensible methodologies. Instead of clinging desperately to the errors of the past, as all other BASICs do, v1ctor took the right path in cleaning up BASIC.

[rant]And I agree with Z!re...get off the high horse, man. The number of years you've been coding means nothing. If anything, stop wasting our time with yout bad attitude.[/rant]

[ShadowWolf]

i don't understand why some people freak when FB does something different in all case's so far when FB does something different it to correct quirks QB had.

i mean if we always got all up tight when anyone ever preposed a changed we still be stuck in the dark age's if anything history has shown things that stay stagnated die off while the things that change live on.