PureBasic Forums - English

nco2k wrote: the last time i compiled an ascii exe was 10 years ago. i dont understand what the fuss is all about.

It's understandable, but doesn't mean it's meaningless. It's actually very simple. So simple I will not say it again especially because it's pointless and not changing anything as everyone here should know by now.

Just to throw my opinion out there...

Since the team has decided to make this change in PB, I wish they would take it ALL THE WAY and support FULL Unicode, perhaps through native UTF-8 strings.

Fixed 16-bit characters are an improvement over 8-bit, but still an incomplete subset of true Unicode.

UTF-8 strings would support all characters, without "wasted" space for 0x00 bytes, still be null-byte-terminated, AND still be backwards-compatible with ASCII files and libs. Plus most modern libs (in my experience) expect UTF-8 strings in/out.

This webpage has many good points: http://utf8everywhere.org/

UTF-8 is great, but for internal representation and comutation it has a big weakness:

You can't seek directly to a specific char, which is a problem for many string functions which requiers an offset to a char. You need to parse all the char to get the right index, which is a bottleneck when dealing with a lot of string op.

Also, It's only shorter for english like language. Chineese/Japanese etc. are actually longer, up to 4 bytes per char.

UTF-8 fits very well for files and API input/output and that's where it's mainly used. OS X uses its own NSString class, Windows uses UTF-16 for its internal API, and it's a good choice for speed.

BTW, currently File lib is already backward compatiable, UTF-8 is the default for all read/write file string ops. Same for XML/Json/Pref libs

Fred wrote:You can't seek directly to a specific char, which is a problem for many string functions which requiers an offset to a char. You need to parse all the char to get the right index, which is a bottleneck when dealing with a lot of string op.

Isn't this always the case with PureBasic ?
As far as I understand PB doesn't store the length of the string so it would have to scan all characters any way to determine if the specified index isn't passed the length of the string.
I'm happy by the way internal ascii representation is dropped.

Fred wrote:BTW, currently File lib is already backward compatiable, UTF-8 is the default for all read/write file string ops. Same for XML/Json/Pref libs

Yes and I appreciate those defaults!

wilbert wrote: I'm happy by the way internal ascii representation is dropped.

Why ? Was it hurting you even if you could just ignore its presence and use unicode only like there's no tomorrow ?

DontTalkToMe wrote:Why ? Was it hurting you even if you could just ignore its presence and use unicode only like there's no tomorrow ?

I like optimizations using assembly code.
So far, if I wanted to post some string related asm code to the forum, I had to split the code into 4 different versions and use CompilerIf to select the right section.

x86, ascii
x86, unicode
x64, ascii
x64 unicode

It's very nice to be able drop 2 out of 4 .
Besides that, almost anyone here wanting 'ascii' mode, doesn't mean truly ascii (char range 0 - 127) but extended ascii which gives a lot of cross platform and codepage problems for the characters within the extended ascii range (128 - 255).

I expected that answer, but that's just because you wanted to support ascii too.

That's why i said "even if you could just ignore its presence and use unicode only" exactly as it is now (but without a choice).

Anyway, ok, that answer my question, basically it's because now it's officially less work and no one can ask you "can you support ascii too?" anymore.

Thanks.

DontTalkToMe wrote:I expected that answer, but that's just because you wanted to support ascii too.

Yes, that's true. I don't have to do that.
But Freds decision has nothing to do with what I like or not. It's just that I understand his decision and see the advantages of it.

Thank you PureBasic Team for this great product, the recent release, and your continuous development work.

Even if it had not paid for itself 100 times over, I am a better programmer thanks to the patience and contributions of many forum members who enjoy using PureBasic as much as I do.

Thank you PureBasic Team for this great product, the recent release, and your continuous development work.

Even if it had not paid for itself 100 times over, I am a better programmer thanks to the patience and contributions of many forum members who enjoy using PureBasic as much as I do.

Exactly!
Thanks for sharing

Lord wrote: PureBasic: Rest in peace. You are not BASIC anymore.

I think It is already not BASIC for years. It's rather C with BASIC syntax and extended STL ^^
Or something like Delphi (with some C stuff also and BASIC syntax).

I don't see problem for it to be unicode-only, ASCII really is abandoned (except microcontrollers :3 but PB doesn't compile to them anyway) and it makes no sense to write pure ASCII-programs for now, even for Windows XP, unless something forces to work with ASCII, but there are many ways to deal with such cases wasting minimum efforts. Executable size of course increases, but man, strings are very minor factor of bloating, bad linker matters much more in this, for example. It is rare case for you to hardcode 500kb (250kb) of strings into exe, but PB linker easily can attach such ammount of trash and unused libraries parts.
So anyway there are many much more important things to be fixed/changed/added than string format-related.

What i want is not a lot of new functions, i want stability and bugfixes for important things.

Is the base stable, for my, new functions are welcome.

Ascii is dead and down, it was before 30 years up to date.
Also in the future x86 is dead and down.
Programming in the future should be easier.
I think this is simple...

Is Unicode programming with PB difficult ?
No, it is simple

Are the compiled files bigger ?
A little, but absolutely not important

Running Unicode compiled files slower ?
Only you use very time sensible string operations, a little, not more
But here is important, stupid programming make software slow, not using Unicode ...

Thanx a lot Fred and team. Vehicle lib is very interesting. Cheers!

oreopa wrote:Thanx a lot Fred and team. Vehicle lib is very interesting. Cheers!

Doc on line here
http://herved25.free.fr/Doc/vehicle/index.html