ElementEncodingType and immutable

Jonathan M Davis jmdavisProg at gmx.com
Fri Nov 22 04:36:11 PST 2013


On Friday, November 22, 2013 12:21:23 bioinfornatics wrote:
> std.string.representation is great but return a numeric array
> instead of numeric type. Ex ubyte[]
>   For ascii but me i try to get ubyte.

Yes. My point is that you have to operate on sequence as immutable(ubyte)[] 
instead of immutable(char)[] if you don't want range-based functions such as 
zip to treat it as a range of dchar. As soon as you pass a string to any 
range-based function that returns a new range type (rather than being able to 
return a portion of the original range like a funtion such as find does), then 
you're going to get a type which is explicitly a range of dchar and does not 
provide access to the underlying chars at all. It will decode them all as 
dchars and return those. So, when you do

foreach( letter, i; zip(sequence, values) )

letter is going to be dchar. If instead you did

foreach( letter, i; zip(sequence.representation, values) )

then it would be ubyte, which you could then cast to char if you wanted to, 
but if you pass sequence directly to zip, then you're going to be iterating 
over dchars and not chars.

Normally, that's what you want, as that's more correct with regards to 
Unicode, but if you really want to operate on the individual chars as you seem 
to, then either you can't use any range-based functions, or you're going to 
need to use std.string.representation to convert the string to an array of the 
integral type that's the same size as the character type and then iterate over 
that instead of char or wchar. All range-based functions are just going to 
treat strings as ranges of dchar and give you dchar when you iterate over 
them.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list