Reading 8 bit chars off a stream

[cartoper]

I am getting a packet of data from an instrument. The strings in the
data packet are null terminted. What is the best way to extract a
string from the data packet?

I am working in .Net 20.

Presently the code reads byte by byte through the packet adding the
value into a List<byte>. The a new byte[] is created based on the
count of the List<byte>. The code iterates though the List<byte> to
populate the byte[]. Finally the byte[] is passed to an instance of
Encoding to get the string.

Is there a better way which does not require looping thourgh the string
twice?

[Kevin Spencer]

Create a buffer to hold the bytes, that is, an array of bytes. Then you
don't need to use the List<byte> and you can flush the buffer whenever you
need to.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.
<ca******@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

I am getting a packet of data from an instrument. The strings in the
data packet are null terminted. What is the best way to extract a
string from the data packet?

I am working in .Net 20.

Presently the code reads byte by byte through the packet adding the
value into a List<byte>. The a new byte[] is created based on the
count of the List<byte>. The code iterates though the List<byte> to
populate the byte[]. Finally the byte[] is passed to an instance of
Encoding to get the string.

Is there a better way which does not require looping thourgh the string
twice?

[Nicholas Paldino [.NET/C# MVP]]

I assume you are using the SerialPort class in the System.IO.Ports
namespace. If not, you might want to look at that.

You might want to consider a MemoryStream instead of a List<byte> to
store the bytes. A MemoryStream will store the bytes as well and allocate
new memory when you need it, but if the message is large, then you can call
the GetBuffer method on the stream to get the internal buffer, whereas with
List<byte> you have to create a new array, and that might be expensive.

Once you have the byte array, you can pass it to the GetString method on
the encoding in one shot, passing the array, as well as the start index and
number of characters to process. This will help in the case of using the
MemoryStream, since you can get the buffer directly and then tell the
encoder just how much to process.

It would be nice if you could use the StreamReader here to perform the
encoding for you, but unfortunately, it buffers the characters from the
stream internally, and if the device isn't going to offer up anything past
the message that it sent, the StreamReader will hang.

Hope this helps.

<ca******@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

I am getting a packet of data from an instrument. The strings in the
data packet are null terminted. What is the best way to extract a
string from the data packet?

I am working in .Net 20.

Presently the code reads byte by byte through the packet adding the
value into a List<byte>. The a new byte[] is created based on the
count of the List<byte>. The code iterates though the List<byte> to
populate the byte[]. Finally the byte[] is passed to an instance of
Encoding to get the string.

Is there a better way which does not require looping thourgh the string
twice?

[herc]

System.Io.Ports, interesting and VERY useful. Currently the connection
is via the Socket Class, but serial connections will need to be
supported, also. Now I know where to go looking.

Your reply has provoked more questions regarding how the code is
working earlier on. Presently the code is using the
Socket.Receive(byte[]) method and passing that into a custom class
called CommsStreamer. CommsStreamer stores the byte[] in an internal
MemoryStream. Each byte is extracted from the memory stream via
ReadByte();

The main reason why each byte is being ripping off one byte at a time
is because the intrument is Big Endian. When extracting a WORD or
DWORD, the conversion is done in the CommsStreamer class back to our
world of Little Endian.

Is there a better way of doing things, when dealing with Big Endian
data?