Re: convert Int32 Unicode character code to its value

[John]

Peter Duniho wrote:

Why not just enumerate all the characters in the string? For example:
>
string strInput = "my string";
>
foreach (char chInput in strInput)
{
// do something with each character
}
>
Is there some specific reason you want to use StringReader?

Well, the code uses a system of building token types and objects out of
the string. I am porting some C++ code that uses putback on the stream
during the processing which can be converted to Peek(). Your suggestion
is valid but I'm not sure it's going to work.

Second, the Encoding class has _no_ methods of that nature. Why would
you expect to find an IsSpace() method in the Encoding class, when there
aren't any methods to classify characters?
>
You can, of course, call Char.IsWhiteSpa ce() on characters once you've
got a valid UTF-16 character to look at.
>

Of course, the Char class, how did I miss that, thanks very much.

Sound advice as usual Peter.

[Peter Duniho]

Re: convert Int32 Unicode character code to its value

On Tue, 07 Oct 2008 20:43:09 -0700, John <no@spam.comwro te:

Peter Duniho wrote:

>Why not just enumerate all the characters in the string? For example:
> string strInput = "my string";
> foreach (char chInput in strInput)
> {
> // do something with each character
> }
> Is there some specific reason you want to use StringReader?

>
Well, the code uses a system of building token types and objects out of
the string. I am porting some C++ code that uses putback on the stream
during the processing which can be converted to Peek(). Your suggestion
is valid but I'm not sure it's going to work.

Well, for sure it can. The main question is how much time and effort you
can afford and are willing to put into the port of the code. I agree that
if you've got working code, often the best approach is to stick with that
code. Of course, that said...that advice taken to it's full implication
means that you don't port the code at all. Just reuse the existing C++
code from your C# application.

As far as alternatives go, I have a poorly-hidden love of state machines.
:) Depending on the complexity of the parsing, you could either maintain
state in a few specific variables in your parser or build a
fully-implemented state machine (not that hard, really). Either approach
would avoid the need to peek at the stream or replace characters that have
been already read.

More work than just porting the code, assuming you can get a clean port.
But it would work and would be perfectly compatible with simply
enumerating the characters.

Pete