Removing 'ASCII' switch from PureBasic
Re: Removing 'ASCII' switch from PureBasic
Strings are already slow as hell with pb (because of some needed dumbproofing), unicode wont make your code significantly slower. Anyway, if this kind of speed is your priority, then PB isn't the tool you need.
And your DLL example is fundamentally biased : of course, in a 1 fonction procedure, it'll look much longer, especially if you write it so badly; but in a real world example it won't be that much of a drag, especially since you could write a nice little macro to do all that.
Unicode is better for everything, said it.
And your DLL example is fundamentally biased : of course, in a 1 fonction procedure, it'll look much longer, especially if you write it so badly; but in a real world example it won't be that much of a drag, especially since you could write a nice little macro to do all that.
Unicode is better for everything, said it.
Re: Removing 'ASCII' switch from PureBasic
Please stay BASIC.
ASCII is BASIC.
If there is to much work: drop SpiderXXXXX
As a hobbyprogrammer, I don't need Unicode and
I don't like to have to change all my recent programs.
As a (not as young as I want to be) hobbyprogrammer,
I don't like new ways of handling just ASCII strings.
As a hobbyprogrammer, I don't like to have double the
size of text in my programs.
But I'm just a hobbyprogrammer.
Maybe I'm just one of a few.
Maybe there are a lot more hobbyprogrammer, but they
are not often in this (international) Forum.
Maybe they also think, I'm just a hobbyprogrammer and
will not be heard because the Pros are making a lot more
noise.
So, I think, the ASCII-switch will be dropped, regardless if
there is a silent majority which will not like this.
ASCII is BASIC.
If there is to much work: drop SpiderXXXXX
As a hobbyprogrammer, I don't need Unicode and
I don't like to have to change all my recent programs.
As a (not as young as I want to be) hobbyprogrammer,
I don't like new ways of handling just ASCII strings.
As a hobbyprogrammer, I don't like to have double the
size of text in my programs.
But I'm just a hobbyprogrammer.
Maybe I'm just one of a few.
Maybe there are a lot more hobbyprogrammer, but they
are not often in this (international) Forum.
Maybe they also think, I'm just a hobbyprogrammer and
will not be heard because the Pros are making a lot more
noise.
So, I think, the ASCII-switch will be dropped, regardless if
there is a silent majority which will not like this.
Re: Removing 'ASCII' switch from PureBasic
It's not like ASCII is basic and Unicode more advanced.Lord wrote:Please stay BASIC.
ASCII is BASIC.
ASCII only covers codes 0-127. Codes 128-255 are extended codes that PB uses but are not cross platform compatible.
Unicode is truly cross platform compatible and not limited to the english language.
If you create international applications, unicode simply is a requirement for it to function properly.
Windows (x64)
Raspberry Pi OS (Arm64)
Raspberry Pi OS (Arm64)
Re: Removing 'ASCII' switch from PureBasic
@wilbert
Thank you for the explanation. Never bothered to look at Unicode as I didn't think I'd ever need it.
However, I'm always pleased to move with the times. So I'll be going with Unicode from now on.
Thanks.
Thank you for the explanation. Never bothered to look at Unicode as I didn't think I'd ever need it.
However, I'm always pleased to move with the times. So I'll be going with Unicode from now on.
Thanks.
DE AA EB
Re: Removing 'ASCII' switch from PureBasic
I agree with you on this.Lord wrote:So, I think, the ASCII-switch will be dropped, regardless if
there is a silent majority which will not like this.
And I really don't have any problems with the change, as it does not affect my programming.
But it does seem like a significant change.
Perhaps instead of a 5.40 branch, it deserves the 6.00 designation?
Keep it BASIC.
Re: Removing 'ASCII' switch from PureBasic
I detect a weird schism developing in this thread. Having both ascii and unicode support is NOT a bad thing for the user. It is a delight and a benefit to me. Clearly, Fred is feeling the burden of dual support and is asking about its necessity.
As of v5.3, I "absolutely" need Unicode compile switch to:
Display international characters in a gadget.
...
That is 10% of my apps. So, for the 90%, I compile Ascii and enjoy the benefits of smaller code and slightly faster execution.
Detour: My idea of modern would be the ability to import C++ libs without having to edit/export its functions in a C++ compiler.
-rant off
As of v5.3, I "absolutely" need Unicode compile switch to:
Display international characters in a gadget.
...
That is 10% of my apps. So, for the 90%, I compile Ascii and enjoy the benefits of smaller code and slightly faster execution.
Detour: My idea of modern would be the ability to import C++ libs without having to edit/export its functions in a C++ compiler.
-rant off
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Removing 'ASCII' switch from PureBasic
Have been using Unicode switch for the past 5 years and can't even recall the last time I've built something purely in ASCII. No problems here whatsoever. All my projects have been converted to Unicode and (some) to x64. I support the move. If you want to stay old school go back to QBASIC.
Intel Core i7 Quad 2.3 Ghz, 8GB RAM, GeForce GT 630M 2GB, Windows 10 (x64)
Re: Removing 'ASCII' switch from PureBasic
16-Bit? That is not Unicode. Unicode needs more than 16 Bit or not? I heard about 100.000 characters...
Re: Removing 'ASCII' switch from PureBasic
I think PureBasic only supports the first plane.Lebostein wrote:16-Bit? That is not Unicode. Unicode needs more than 16 Bit or not? I heard about 100.000 characters...
http://en.wikipedia.org/wiki/Plane_(Unicode)
Windows (x64)
Raspberry Pi OS (Arm64)
Raspberry Pi OS (Arm64)
Re: Removing 'ASCII' switch from PureBasic
@Lebostein
According to the manual PB uses UCS-2 internally, so 16 bits.
Also the .u type is defined as 16 bit and this is a pretty strong hint it's 16 bits.
UTF-8, UTF-16, UCS-2 are different types of encoding for unicode chars.
What you are referring to is UTF-16, which will continue to be filled with the most absurd stuff if history is of any indication.
According to the manual PB uses UCS-2 internally, so 16 bits.
Also the .u type is defined as 16 bit and this is a pretty strong hint it's 16 bits.
UTF-8, UTF-16, UCS-2 are different types of encoding for unicode chars.
What you are referring to is UTF-16, which will continue to be filled with the most absurd stuff if history is of any indication.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: Removing 'ASCII' switch from PureBasic
What about an unsigned Byte and Word variable? At the moment we have to abuse the Ascii and Unicode types to handle that...
-
- Addict
- Posts: 4527
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: Removing 'ASCII' switch from PureBasic
That's no "abuse". Those variable types are just misnamed.Lebostein wrote:What about an unsigned Byte and Word variable? At the moment we have to abuse the Ascii and Unicode types to handle that...
(And that has nothing got to do with the topic of this thread.)
- Bananenfreak
- Enthusiast
- Posts: 519
- Joined: Mon Apr 15, 2013 12:22 pm
Re: Removing 'ASCII' switch from PureBasic
What about OGRE? Paths will be still in ASCII...
Yet, we can´t use äüöß or Russian letters,... in paths, but OGRE is OGRE and it will stay on the ASCII-side even we have only Unicodesupport, or not?
EDIT: I think there is no problem.
Yet, we can´t use äüöß or Russian letters,... in paths, but OGRE is OGRE and it will stay on the ASCII-side even we have only Unicodesupport, or not?
EDIT: I think there is no problem.
So what I have to do to get my program working?All strings in PB will be handled as UCS2 (16-bit) strings internally. So if you used "@String$" somewhere in your code, change are high it won't work anymore (if dealing which an API for example)
Re: Removing 'ASCII' switch from PureBasic
It depends on the function where you used '@String$'. With most WinAPI functions there shouldn't be a problem, becauseBananenfreak wrote:So what I have to do to get my program working?All strings in PB will be handled as UCS2 (16-bit) strings internally. So if you used "@String$" somewhere in your code, change are high it won't work anymore (if dealing which an API for example)
they automatically use the Unicode version then (FunctionA vs. FunctionW).
PB Functions that work with Pointers to Strings need to use '*p + sizeOf(Character)' instead '*p + 1' to move to the next character.
That's what most guys here do anyway, for years. So no problems with that, too.
Many codes here in the forum will work like before, because many people already using Unicode for years,
and they made sure that codes worked in both modes.
For external functions (DLLs, wrappers, static lib imports), you may need to alter the function declarations or Prototypes.
This can be done with Pseudo-Types like p-ascii and p-utf8. If you already used the correct (pseudo-)types, you don't need to change anything.
Little John wrote:That's no "abuse". Those variable types are just misnamed.
Code: Select all
Macro ub:a:EndMacro
Macro uw:u:EndMacro
Define uByte.ub = $FF
Define uWord.uw = $FFFF
- Didelphodon
- PureBasic Expert
- Posts: 448
- Joined: Sat Dec 18, 2004 11:56 am
- Location: Vienna - Austria
- Contact:
Re: Removing 'ASCII' switch from PureBasic
Thx for this article it's *really* well written. Especially compared to those book chapters with dozens of pages discussing character(s)/-sets/-encoding/... which I never managed to read entirely due to sinking motivation.PB wrote:I used to avoid Unicode like the plague until I read this article:
http://www.joelonsoftware.com/articles/Unicode.html
PureBasic is moving in the right direction. Unicode is the future.
However, still I have a lot of code around from times before PureBasic's Unicode switch which I would have to check.
Cheers,
Didel.
Go, tell it on the mountains.