Bug Reports - Printable Version

Bug Reports - Printable Version

+- Qbasicnews.com (http://qbasicnews.com/newforum)
+-- Forum: General (http://qbasicnews.com/newforum/forum-6.html)
+--- Forum: General/Misc (http://qbasicnews.com/newforum/forum-18.html)
+--- Thread: Bug Reports (/thread-5202.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Bug Reports - zydon - 01-09-2005

Quote:Just added literal strings with escape chars, as Antoni suggested, you will be able to do:

Code:
const crlf = "~n"

On next release.. and ~t, ~13 ~0 (don't do this! etc.. parsing is enabled by OPTION ESCAPE.

I hope you will not use ~ as an ESC characters re-presentations in FB. I rather willing to accept \n, \t \x00 as usually written in C/C++ in their printf and using #ESCAPECHARS ON/OFF as a token.

Code:
#ESCAPECHARS ON

PRINT "This is first line \nThis is second line"

#ESCAPECHARS OFF

'PRINT-OUT:

'-----------------------

'This is first line

'This is second line

'-----------------------

If you want simpler, you could use ESCAPE ON/OFF token. Using ~ will make things even more confusing for basic users.

Bug Reports - Sterling Christensen - 01-09-2005

Quote:FB won't allow different types passed by reference anymore (unless they are constants)

Ack! Is that the way it's going to be from now on?

Bug Reports - v3cz0r - 01-09-2005

Do you prefer:

Code:
declare sub foo( a as short )

foo a%

if( a% = 1 ) then end

a% won't be ever changed that way.

Code:
declare sub bar( a as integer )

bar a!

I get a "^ Parameter type mismatch" with QB4.5, now a!*rnd is accepted.. call that a fucked language, it is.

Bug Reports - subxero - 01-09-2005

The error reporting in FB is going to hell :-P
Well, probably not, but I think there's not much to gain from upgrading to .10. Version .09 compiled everything I had very well, and .10's FBC.exe keeps returning "128" without telling me anything else. So I tracked it down to being an undeclared variable (I'm using OPTION EXPLICIT) - I wish FBC would've told me that. Took a good 15 minutes to notice. :-P
Also, when I forgot to add a DECLARE for a SUB, FBC returned "128" as well without telling me anything more. And the line numbers, when reported, are insanely wrong (line 5323? I've only got 300-some lines.)
You should fix the simple casts too (e.g., passing a SINGLE/DOUBLE to an INTEGER parameter would auto-cast, and vice-versa. We are striving for compatibility, aren't we?)

Please don't turn FB into C. I hate C. C raped my best friend. :lol:

Anyways, not to bitch. FB rules, but it seems .10 breaks more things than it fixes. Sorry for the bad news.

Bug Reports - v3cz0r - 01-09-2005

It would help me a lot if you cold show me the code that generated that error, as i never saw it happening, thanks -- if i can't reproduce the error, hey, i'm not magic.

As QB does that crap, arg as byref type and expression as anything else but strings/udts are accepted again..

Bug Reports - Sterling Christensen - 01-09-2005

Quote:I get a "^ Parameter type mismatch" with QB4.5, now a!*rnd is accepted.. call that a @Â£$Â£ language, it is.

OIC... it's cool then.

Bug Reports - v3cz0r - 01-09-2005

Having to do "\\" is confusing to basic users -- even C coders forget about that, i do -- ~ is seldom used, ^ is valid in USING.. escape will be ~, if you turned it on then you know what you are doing, right?

OPTION ESCAPE is already bad, if you forget it your app will fail, OPTION ESCAPE ON|OFF is even worse, as any OPTION and DEF### is, they make the language context-dependent, where bugs appear for no "apparent" reason, but it's QB-like.. nothing else to do.

Bug Reports - zydon - 01-09-2005

In that case, just drop the idea of having $OPTION ESCAPE and add CR, LF, CRLF, TAB and QUOTE keywords would be more peaceful to coder minds.

Example1:

Code:
PRINT "Value a:";TAB;a;CRLF;"Value b:";TAB;b

'-- or --

PRINT "Value a:"+TAB+str$(a)+CRLF+"Value b:"+TAB+str$(b)

'PRINT-OUT:

'--------------------------------------

Value a:        1234

Value b:        5678

'--------------------------------------

Example2:

Code:
PRINT QUOTE+"This word"+QUOTE

'PRINT-OUT:

'--------------------------------------

"This word"

'--------------------------------------

Then, it would be readable source code for that purposes.

Btw, here is the most needed constants for the above needs:

Code:
#DEFINE CR      &H0D

#DEFINE LF      &H0A

#DEFINE CRLF    &H0A0D

#DEFINE QUOTE   &H22

#DEFINE TAB     &H09

#DEFINE ESC     &H1B

#DEFINE BELL    &H07

Bug Reports - v3cz0r - 01-09-2005

TAB is already a keyword, CRLF is used a lot as var names, would break old sources, as any simple named pre-defined constant will. They would have to be called like "fbNEWLINE", what looks not that great - ppl forget the "fb" or type "fp" and BASIC with its auto-vars will accept that as valid.

So what makes \n more readable than ~n, while people want the pre-processor directives inside the comments '$? Forget the readability..

Bug Reports - na_th_an - 01-09-2005

~n is fine to me. I don't really care. I can't see why a simple symbol is such an issue for those people Tongue