iOS Returning an index from a string character

[charmofmaking]

I am setting an index within a sprite sheet based on reading each character in a string of text.

So @"ABC" returns 12,13,14 and so on... The code below works but is there a simple (better) way of doing this?

I seems to remember CHR$() and the such like from BBC BASIC but I am struggling to find anything like that for NSString.

//default to char space
spriteTextureX[s]=38;spriteTextureY[s]=2;spriteTextureS[s]=textureSize32;//NOT default 128
						
if(messageCharPos<messageLen){
                
	    NSString *aChar = [messageText substringWithRange:NSMakeRange(messageCharPos, 1)];
						
	    //NSLog(@"char at pos %i is %@",messageCharPos,aChar);
						    
	    if([@"A" isEqualToString:aChar]) {spriteTextureX[s]=12;}
	    if([@"B" isEqualToString:aChar]) {spriteTextureX[s]=13;}
	    if([@"C" isEqualToString:aChar]) {spriteTextureX[s]=14;}
	    // and so on...

	    messageX+=32;//inc x
	    messageCharPos++;//inc pos along the string						    
						           
}//endif within len of string

Hope someone can help

 

[robbieduncan]

Do you absolutely, definitely have to use a NSString or would a char[] be acceptable? All those expensive method calls to essentially use a NSString as an array!

 

[PhoneyDeveloper]

You can use a dictionary to associate the keys with the values: @"A" : [NSNumber numberWithInt:12]

NSInteger value = [[self.myDictionary objectForKey:aChar] integerValue];
spriteTextureX[s]=value;

 

[charmofmaking]

Nice, so I could do something like

char alphaBet [] = "ABC";
int base = 12;
for (int n=0; n<3; n++) {
   if([alphaBet[n] isEqualToString:aChar]) {spriteTextureX[s]=base+n;}
}

Is there a simpler way to compare the two strings instead of isEqualToString?

Do you absolutely, definitely have to use a NSString or would a char[] be acceptable? All those expensive method calls to essentially use a NSString as an array!

 

[Duncan C]

Nice, so I could do something like

char alphaBet [] = "ABC";
int base = 12;
for (int n=0; n<3; n++) {
   if([alphaBet[n] isEqualToString:aChar]) {spriteTextureX[s]=base+n;}
}

Is there a simpler way to compare the two strings instead of isEqualToString?

For single characters, you should use arrays of unichar, and characterAtIndex to extract a character from a string.

With the unichar data type you can use == to compare characters. (Unless you need to ignore case or diacritical marks or something like that.

 

[PhoneyDeveloper]

If your string is pure ascii then all you need is a lookup table. This would be a 256 char array with the correct value in each member. If your string is not pure ascii you should probably use a dictionary like I mentioned earlier.

int value = myArray[achar];
spritTextureX[s] = value;

Unless you are an expert in unicode you should not use the unichar data type or characterAtIndex.

 

[Duncan C]

If your string is pure ascii then all you need is a lookup table. This would be a 256 char array with the correct value in each member. If your string is not pure ascii you should probably use a dictionary like I mentioned earlier.

int value = myArray[achar];
spritTextureX[s] = value;

Unless you are an expert in unicode you should not use the unichar data type or characterAtIndex.

Umm, why? The unichar type is a simple scalar data type, and characterAtIndex returns a single character. Why does that require expert-level knowledge?

 

[ArtOfWarfare]

Umm, why? The unichar type is a simple scalar data type, and characterAtIndex returns a single character. Why does that require expert-level knowledge?

I might be mistaken, but I thought there were a lot of unichars that occupy more than one index, IE, a lot of the emoji characters take up two indices.

 

[Duncan C]

I might be mistaken, but I thought there were a lot of unichars that occupy more than one index, IE, a lot of the emoji characters take up two indices.

Take up two indices? No.

Unicode is a 16 bit character set. Unichars are 16 bits.

Some encodings like UTF8 play games where standard ASCII (Unicode page 0) characters only take 8 bits, and other characters are encoded using multiple 8-bit characters. (Kind of like the way BASE64 encoding converts binary data into the 64 ASCII characters that you can send through any brain-damaged EBCDIC/7-bit ASCII computer from the 1960s.)

However, NSString hides that mess from you. You can just treat an NSString as an array of 16-bit unicode characters and it all works perfectly. Then, when you want to save it to a file, you save it using an encoding like UTF8, and it handles THAT for you too.

 

[chown33]

Unicode is a 16 bit character set.

No. For example, emoticons:

http://www.unicode.org/charts/PDF/U1F600.pdf
Range: U1F600-1F64F
​

There are other less trivial examples, such as Egyptian hieroglyphs and Deseret.

Full list of code charts in PDF:
http://www.unicode.org/charts/PDF/

Any chart with more than 4 hex digits is necessarily outside the Basic Multilingual Plane, i.e. requires more than 16 bits.
http://en.wikipedia.org/wiki/Unicode_plane

Unichars are 16 bits.

If you mean the C typedef (spelled 'unichar', all lower-case), then yes. But not every Unicode code-point can be represented as a single unichar. See the UTF-16 encoding.

Some encodings like UTF8 play games where standard ASCII (Unicode page 0) characters only take 8 bits,

Standard ASCII is a 7-bit code. So it only takes 7 bits, not 8.
http://en.wikipedia.org/wiki/ASCII

 

[ArtOfWarfare]

I feel smart now that chown33 has backed up what I said.

 

[chown33]

I feel smart now that chown33 has backed up what I said.

And then the feeling wears off and all you're left with is a penchant for regular expressions and sarcasm.

 

[PhoneyDeveloper]

The unichar type is a simple scalar data type, and characterAtIndex returns a single character.

Do you know what a combining character is? precomposed, decomposed characters?

Some characters can be represented in multiple ways. characterAtIndex will allow you to shoot yourself in the foot, unless you're an expert. You can be lucky for a little while, then get shot.

 

[Duncan C]

No. For example, emoticons:

http://www.unicode.org/charts/PDF/U1F600.pdf
Range: U1F600-1F64F
​

There are other less trivial examples, such as Egyptian hieroglyphs and Deseret.

Full list of code charts in PDF:
http://www.unicode.org/charts/PDF/

Any chart with more than 4 hex digits is necessarily outside the Basic Multilingual Plane, i.e. requires more than 16 bits.
http://en.wikipedia.org/wiki/Unicode_plane


If you mean the C typedef (spelled 'unichar', all lower-case), then yes. But not every Unicode code-point can be represented as a single unichar. See the UTF-16 encoding.



Standard ASCII is a 7-bit code. So it only takes 7 bits, not 8.
http://en.wikipedia.org/wiki/ASCII

I stand corrected.

 

[MattInOz]

Do you know what a combining character is? precomposed, decomposed characters?

Some characters can be represented in multiple ways. characterAtIndex will allow you to shoot yourself in the foot, unless you're an expert. You can be lucky for a little while, then get shot.

Sorry if i'm missing something but....

Isn't that sort of irrelevant if the OP has control over the strings of text used to index the sprite table?

If one of those characters got in it's going to produce an out range error on the sprite look up if the original code is anything to go by.

Why not just make the strings so that -characterAtIndex returns a unichar of the right integer value (typedef unsigned short unichar)?
Or have an offset by creating a variable of the unichar at the zero index (i.e. 'a') then minus that from the result to find a location in the sprite table.

 

[PhoneyDeveloper]

IMO, it's a slippery slope. It's possible that if the characters are known to be only ascii then there would be no problem. I don't see the advantage over using the dictionary like I mentioned. If the letters are typed in I don't see how they're restricted to ascii. If they're not typed in then I don't see the problem.

Having said that, I don't really understand how letters that are typed in correspond to indexes into a sprite sheet.

 

[xArtx]

So long as it's guaranteed ASCII, am I missing something here?

if (messageCharPos<messageLen){
spriteTextureX[s] = char_youre_looking_at - 53; // ("A",41h,65d) - 53 = 12.
}                                               // ("B",42h,66d) - 53 = 13, etc.

and handle character that is unsupported in your spritesheet..

if (spriteTextureX[s] > lowerbound || spriteTextureX[s] > upperbound) {
// point to spritesheet address for unsupported characters, like a space.
}

Since you called it a "message" I'm guessing input comes from the program itself, and is ASCII.

 

[charmofmaking]

Yes it is ASCII so if there is a simple way to get the ASCII code of a single character held in aChar string that would be perfect...

NSString *aChar = [messageText substringWithRange:NSMakeRange(messageCharPos, 1)];

INT what_to_put_here = ??????; //ASCII code of aChar string

//NSLog(@"char at pos %i is %@ with ASCII code of %i",messageCharPos,aChar,what_to_put_here);

So the question is how do I return an integer containing the ASCII code of aChar in the code above?

So long as it's guaranteed ASCII, am I missing something here?

if (messageCharPos<messageLen){
spriteTextureX[s] = char_youre_looking_at - 53; // ("A",41h,65d) - 53 = 12.
}                                               // ("B",42h,66d) - 53 = 13, etc.

and handle character that is unsupported in your spritesheet..

if (spriteTextureX[s] > lowerbound || spriteTextureX[s] > upperbound) {
// point to spritesheet address for unsupported characters, like a space.
}

Since you called it a "message" I'm guessing input comes from the program itself, and is ASCII.

 

[robbieduncan]

I come back to my question right at the top: do you absolutely have to use NSString? Or can you use an old-school C string/character array?

 

[Duncan C]

Yes it is ASCII so if there is a simple way to get the ASCII code of a single character held in aChar string that would be perfect...

NSString *aChar = [messageText substringWithRange:NSMakeRange(messageCharPos, 1)];

INT what_to_put_here = ??????; //ASCII code of aChar string

//NSLog(@"char at pos %i is %@ with ASCII code of %i",messageCharPos,aChar,what_to_put_here);

So the question is how do I return an integer containing the ASCII code of aChar in the code above?

Since it's guaranteed to be ASCII, use charAtIndex, which returns a unichar. For ASCII characters, the value of the unichar will be the ASCII code of the character.

Something like this:

for (int index = 0; index < messageText.length; index++)
{
  unichar aChar = [messageText characterAtIndex];
  NSLog(@"Character at index %d = %d", index, aChar);
}

 

[charmofmaking]

I create the string so it could be NSless. If there is a pure and simple way to walk through a string and return the ASCII of each character as an int that would be very interesting.

I come back to my question right at the top: do you absolutely have to use NSString? Or can you use an old-school C string/character array?

----------

Finally got there!

It seems that my continued failure to grasp C makes the sucessful builds all the sweeter

output:
char at pos 0 is A with code of 65 as int 65
char at pos 1 is B with code of 66 as int 66
char at pos 2 is C with code of 67 as int 67

from:

//get character at pos
NSString *aChar = [gameMessageText substringWithRange:NSMakeRange(messageCharPos, 1)];
            
//get ASCII code of character at pos
NSNumber *aCode = [NSNumber numberWithUnsignedChar:[gameMessageText characterAtIndex:messageCharPos]];
                            
//and now as an integer 
int aInt = [aCode intValue];
                            
//good news everyone!
NSLog(@"char at pos %i is %@ with code of %@ as int %i",messageCharPos,aChar,aCode,aInt);

Since it's guaranteed to be ASCII, use charAtIndex, which returns a unichar. For ASCII characters, the value of the unichar will be the ASCII code of the character.

So long as it's guaranteed ASCII, am I missing something here?

 

[Duncan C]

I create the string so it could be NSless. If there is a pure and simple way to walk through a string and return the ASCII of each character as an int that would be very interesting.



----------

Finally got there!

It seems that my continued failure to grasp C makes the sucessful builds all the sweeter

output:
char at pos 0 is A with code of 65 as int 65
char at pos 1 is B with code of 66 as int 66
char at pos 2 is C with code of 67 as int 67

from:

//get character at pos
NSString *aChar = [gameMessageText substringWithRange:NSMakeRange(messageCharPos, 1)];
            
//get ASCII code of character at pos
NSNumber *aCode = [NSNumber numberWithUnsignedChar:[gameMessageText characterAtIndex:messageCharPos]];
                            
//and now as an integer 
int aInt = [aCode intValue];
                            
//good news everyone!
NSLog(@"char at pos %i is %@ with code of %@ as int %i",messageCharPos,aChar,aCode,aInt);

A unichar is a typedef for unsigned short. (a short unsigned integer). There is no reason to create an NSNumber and get it's intVAlue, and this will create an extra object for every character you parse.

You are also creating an unneeded single-character string object for every time this code is called.

Memory allocation is expensive, so creating an object for every character will be slow. If you are parsing thousands of characters it will start bogging your program down.

All that code could be replaced with:

unichar aChar = [gameMessageText characterAtIndex: 0];
NSLog(@"char at pos %i is %@ with code of %@ as int %i",messageCharPos,aChar,aCode,aInt);

 

[chown33]

unichar aChar = [gameMessageText characterAtIndex: 0];
NSLog(@"char at pos %i is [COLOR="Red"]%@[/COLOR] with code of [COLOR="Blue"]%@[/COLOR] as int %i",messageCharPos,aChar,aCode,aInt);

The red-hilited format specifier is wrong. %@ is for objects. The unichar type is not an object type. Use %C instead.

The blue-hilited format specifier presumes the existence of an aCode object. Which was eliminated as superfluous. So simply take out anything dealing with aCode. The "code" of a unichar is its numeric value, which is already being logged as %i. One could also show the code as hex (%x), but as long as aCode doesn't exist, it can't be logged.


https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html

It seems that my continued failure to grasp C makes the sucessful builds all the sweeter

You should spend the time needed to remedy the C deficit.

 

[Duncan C]

The red-hilited format specifier is wrong. %@ is for objects. The unichar type is not an object type. Use %C instead.

The blue-hilited format specifier presumes the existence of an aCode object. Which was eliminated as superfluous. So simply take out anything dealing with aCode. The "code" of a unichar is its numeric value, which is already being logged as %i. One could also show the code as hex (%x), but as long as aCode doesn't exist, it can't be logged.


https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html



You should spend the time needed to remedy the C deficit.

Oops. I didn't pay any attention to the log statement, and just copy-and-pasted it from the OP's post. Good catch.

 

[charmofmaking]

output:
aUni is a short unsigned int of 65 representing A
aUni is a short unsigned int of 66 representing B
aUni is a short unsigned int of 67 representing C

from:

unichar aUni = [gameMessageText characterAtIndex: messageCharPos];
NSLog(@"aUni is a short unsigned int of %u representing %C",aUni,aUni);

Perfect Thank you for taking the time to help me out, its much appreciated.

A unichar is a typedef for unsigned short. (a short unsigned integer)...