Resolved Returning an index from a string character

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!

 

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

Code:

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

 

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.

 

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.

Code:

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?

 

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.

 

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 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.

 

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.

 

I stand corrected.

 

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.

 

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.

 

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

Code:

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..

Code:

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.

 

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?

 

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:

Code:

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

 

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:

Code:

unichar aChar = [gameMessageText characterAtIndex: 0];
NSLog(@"char at pos %i is %@ with code of %@ 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...eptual/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.