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