.a and .u

[blueznl]

4.40b1 now features unsigned vars, which is great! But, being the pain in the but I am, I'd like to have it changed

Wouldn't it be better for future consistency to do it differently?

4.40b1:

- Added: '.a' (ascii) and '.u' (unicode) native type to provide native unsigned byte and word.

What I think would be a better solution:

.b = byte
.ub = unsigned byte
.w = word
.uw = unsigned word
.l = long
.ul = unsigned long
.q = quad
.uq = unsigned quad

[freak]

I don't think there will be unsigned long or quad.

[blueznl]

When we go to 128 bits we will see them

Anyway, it's easier to read and less confusing IMHO.

[Fred]

These are primary for use to manipulate characters (ascii or unicode) indepently of the main 'Unicode' flag (unlike the .c type). Indeed, it works perfectly as well for unsigned byte and word. That said we don't plan to add further unsigned types.

[blueznl]

Okaaaaayeeee. I understand. Unsigned longs would have been nice, but unsigned bytes are more important

Let me make my last final pitch for .ub versus .a, I just find it more readable

Then again, you're the boss, so I'll go and stand humbly in my corner if you tell me so

[milan1612]

Okaaaaayeeee. I understand. Unsigned longs would have been nice, but unsigned bytes are more important

Let me make my last final pitch for .ub versus .a, I just find it more readable

Then again, you're the boss, so I'll go and stand humbly in my corner if you tell me so

Code: Select all

Macro ub
  a
EndMacro

Define ubyte.ub = 255

[THCM]

As far as I remember ASCII uses only 7 bits and I also would prefer something like .ub or at least another explanation should be used as ASCII. I also would like to see at least unsigned longs in the future. It would allow us to use cheap SIMD like coding without the need for inline assembly and or special instructions: http://cobweb.ecn.purdue.edu/~hankd/SWAR/over.html

[nco2k]

i kind of like the naming a and u. too bad there are no plans for an unsigned long.

c ya,
nco2k

[blueznl]

And I promised myself not to react... oh well, can't help myself

Unicode has nothing to do with 16 8 25 or 32 bits, so calling an unsigned 16 bits a 'unicode' is rather misleading, if not entirely wrong

Unicode is the whole character set, where each codepoint can be identified using UTF8 or UTF16 (or UTF32, whatever you like ).

It's still unclear to me if XP and later incarnations do full Unicode or not, I suspect they don't but I'm not entirely sure. Couldn't find a definite statement on that

Same thing goes for ASCII, there isn't one standard if you look at the 8 bit versions. The 'real' thing is 7 bits... not 8.

So .u indicates unicode, which is either 8 or 16 or 32 BITS (yeah, I made a typo and said bytes the first time around), and .a indicates ascii which is 7 bits... uh... .ub and .uw after all?

[freak]

It fits the #PB_Ascii and #PB_Unicode flags used for string operations. I know that these do not fit the technical terms 100% either, but that is history.

[klaver]

we don't plan to add further unsigned types.

Why?

[mback2k]

If we only get .a and .u because of the ASCII/Unicode thing, I think there should also be .as and .us (or something similiar) for ASCII/Unicode strings that don't depend on the compiler flag.

Or make .c[x], .a[x] and .u[x] behave like fixed strings.

[blueznl]

I said I wouldn't return to this subject, but I cannot help myself. Let me make my final fevered pitch for .ub and .uw...

1. First, there's something missing, an equivalent of the standard .BYTE structure but then for unsigned characters (yes, I know, I can easily build one myself, but that's not the point here).

Code: Select all

x.b = 247
*a = @x
Debug *a\b
;
y.a = 247
*a = @x
Debug *a\b

2. Now if .a stands for 'ascii' then one would assume something like this should work...

Code: Select all

; not looking as nice (though it doesn't work anyway as there's no .ASCII struct :-))
;
*a.BYTE
a.b = 1
*a = @a
Debug *a\b
;
*b.ASCII
b.a = 2
*b = @b
Debug *b\a

Not that it works but it's only to illustrate I think the *b.ASCII is rather misleading, as it has nothing to do with ASCII but only with unsigned bytes. But, if .a stands for 'Ascii' then it would make sense to call the build in structure .ASCII... brrr.

3. Looking better. (Sorry, couldn't help myself )

Code: Select all

; looking better
;
*a.BYTE
a.b = 1
*a = @a
Debug *a\b
;
*b.UBYTE
b.ub = 2
*b = @b
Debug *b\ub

In this proposed syntax it is much clearer what is intended. It's readable. Please compare that with the syntax above under 2.

I know it's up to the devs to decide on this and that I'll probably have to live with it but still, before 4.40 goes final, this may be the right time to suggest such a change before its too late. I admit it's not essential, it just looks a lot better...

<Edit 1>

Nco2k just added his own wish here http://www.purebasic.fr/english/viewtopic.php?t=38657 which I think also illustrates the confusion this naming scheme may cause.

<Edit 2>

My final comment: I abosulutely *love* access to unsigned bytes! And I guess for many of the users that has little to nothing to do with the fact that Ascii characters fit in an unsigned byte...

[Thorium]

That said we don't plan to add further unsigned types.

That makes me a little bit sad. I realy hoped that full unsigned support is coming. I know there is a workaround for unsigned, but thats a trade for performance. And it's a bug magnet. ^^ I had more than one time a bug related to the fact that the variables are not unsigned.

Is there a technical reason for your decision to not implement unsigned types. Like you have to rewrite to much of the existing code.
Or is it just a design decision. Well if it is a design decision i can not understand it.

[luis]

Is there a technical reason for your decision to not implement unsigned types.

I remember this answer:

http://www.purebasic.fr/english/viewtopic.php?t=6896

PS: I would like unsigned me too...