On Jan 11, 2009, at 2:22 PM, Kyle Sluder wrote:
On Sun, Jan 11, 2009 at 1:56 PM, Greg Titus
wrote:
Cocoa does use UTF-16 as the encoding for its unichar type in
NSStrings, but
the low 7-bits of UTF-16 (characters 0-127) are identical to the
ASCII
encodings, so you can cast (char)'7' or (un
On Sun, Jan 11, 2009 at 1:56 PM, Greg Titus wrote:
> Cocoa does use UTF-16 as the encoding for its unichar type in NSStrings, but
> the low 7-bits of UTF-16 (characters 0-127) are identical to the ASCII
> encodings, so you can cast (char)'7' or (unichar)'7' and get 0x37 either way
> and it'll be i
On Sun, Jan 11, 2009 at 1:24 AM, wrote:
> This is what I did in my project, using the code below. I can't
> help feeling that this code is dirty because it relies on the character
> for the "j" digit being indexed as unichar number j+48. Can anyone
> tell me what would be the clean way to do th
On Jan 11, 2009, at 10:48 AM, Kyle Sluder wrote:
On Sun, Jan 11, 2009 at 2:50 AM, Ken Thomases
wrote:
Sure it would. Both unichar (as typedef'd) and char are integer
types in C.
'7' is another way of writing a number, although not the number 7.
Which
number depends on the encoding of yo
On Sun, Jan 11, 2009 at 2:50 AM, Ken Thomases wrote:
> Sure it would. Both unichar (as typedef'd) and char are integer types in C.
> '7' is another way of writing a number, although not the number 7. Which
> number depends on the encoding of your source file, but in most modern
> systems it wou
On Jan 11, 2009, at 9:41 AM, Adam R. Maxwell wrote:
On Jan 11, 2009, at 1:50 AM, Ken Thomases wrote:
On Jan 11, 2009, at 1:28 AM, ewan.dela...@math.unicaen.fr wrote:
If you must work character-by-character,
use character constants (e.g. >'0' or '9')
In that (unlikely) situation, how woul
Le 11 janv. 09 à 15:41, Adam R. Maxwell a écrit :
On Jan 11, 2009, at 1:50 AM, Ken Thomases wrote:
On Jan 11, 2009, at 1:28 AM, ewan.dela...@math.unicaen.fr wrote:
If you must work character-by-character,
use character constants (e.g. >'0' or '9')
In that (unlikely) situation, how would
On Jan 11, 2009, at 1:50 AM, Ken Thomases wrote:
On Jan 11, 2009, at 1:28 AM, ewan.dela...@math.unicaen.fr wrote:
If you must work character-by-character,
use character constants (e.g. >'0' or '9')
In that (unlikely) situation, how would I test, say, equality
of characters ? For example, if
On Jan 11, 2009, at 1:28 AM, ewan.dela...@math.unicaen.fr wrote:
If you must work character-by-character,
use character constants (e.g. >'0' or '9')
In that (unlikely) situation, how would I test, say, equality
of characters ? For example, if I needed to know whether
character number j in aSt
Thanks Ken and Steve,
for the variety of clean solutions you offered. Just out of
curiosity, I should like to return to a point mentioned by
Ken :
>If you must work character-by-character,
>use character constants (e.g. >'0' or '9')
In that (unlikely) situation, how would I test, say, equali
On Jan 11, 2009, at 12:24 AM, ewan.dela...@math.unicaen.fr wrote:
I have a Cocoa app that performs some computations on
large integers (but still in the "unsigned long long" range), some
of which are entered by the user in a NSTextField.
Do you really need to exceed the long long range? NSS
On Sun, Jan 11, 2009 at 12:24 AM, wrote:
> I have a Cocoa app that performs some computations on
> large integers (but still in the "unsigned long long" range), some
> of which are entered by the user in a NSTextField.
>
> The problem , of course, is that NSControl has no
> -(unsigned long lo
Hello all,
I have a Cocoa app that performs some computations on
large integers (but still in the "unsigned long long" range), some
of which are entered by the user in a NSTextField.
The problem , of course, is that NSControl has no
-(unsigned long long)unsignedLongLongValue metho
13 matches
Mail list logo
