Bug in PRINT <positive number>?

[BasicJan]

If a positive number is converted to a string (STR$(<positive number>) or printed (PRINT <positive number>) in QuickBasic a space is placed before the number.

In FreeBasic no space is added if a positive number is converted to a string (STR$). However, if a positive number is printed, a space is still added!!

Try

PRINT "TEST";100

Was this meant to behave like this, or should there be no space, like the STR$-statement?

[mjs]

Yes, it's meant to be like this.

Regards,
Mark

[urger]

This was deliberately changed in FB.

[1000101]

Why?

Just to break things and require people to check for lead spaces?

Stupid reasons people.

[v1ctor]

STR$ works that way since release 0.0, that's listed in the wiki docs as well: http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgStr

[mjs]

It was a design decision v1ctor made. I personally don't care about leading spaces for non-negative numbers.

I guess that v1ctor found this leading space for STR$ annoying and therefore removed it in FB to get rid of the need of the "LTRIM$(STR$(num%))" stuff. However, the leading space is kept when printing numbers to ensure that the output isn't broken when compiling old QB sources with FB.

Regards,
Mark

[JJ2005]

It was a design decision v1ctor made. I personally don't care about leading spaces for non-negative numbers.

I guess that v1ctor found this leading space for STR$ annoying and therefore removed it in FB to get rid of the need of the "LTRIM$(STR$(num%))" stuff. However, the leading space is kept when printing numbers to ensure that the output isn't broken when compiling old QB sources with FB.

Regards,
Mark

Personally I prefer no spaces, and it should be consistent between screen and other outputs. Screen no, printer yes makes no sense.
Inserting a space in old QB sources would be truely cumbersome, though. Imagine a "Print a1;a2;a3" etc. statement...
Best option imho would be an "OPTION LEAD SPACES ON" (default: OFF) for those who rely on QB sources.