[RESOLVED] Byte Array Concatination

Been struggling with this thread: http://www.vbforums.com/showthread.p...ding-This-Code

The code in question uses the MidB function to concatinate two Arrays together. One happens to be a Variant the other a Byte Array.

However, this works:

Code:

---

Private Sub Command1_Click()
Dim bytA(9) As Byte
Dim bytB(9) As Byte
Dim bytC() As Byte
Dim intI As Integer
For intI = 0 To 9
    bytA(intI) = CByte(intI + &H10)
Next intI
For intI = 0 To 9
    bytB(intI) = CByte(intI + &H20)
Next intI
bytC = MidB(bytA, 1) & MidB(bytB, 1)
For intI = 0 To UBound(bytC)
    Debug.Print Hex(bytC(intI)); " ";
Next intI
End Sub

---

The net result is that the Array bytC ends up containing all the elements of bytA and bytB (exactly what you'd expect if they all were string variables, rather than Byte Arrays, and Mid$ was used)

What I don't understand is why it works. The MidB documentation suggests that the first Argument should be a String and here we are giving it a byte Array.

I would have expected a Type Mismatch error. I'd have thought it would have required a BSTR pointer rather than a 'direct' pointer to the string argument.

I understand that MidB returns bytes rather than characters and is primarily used in DBCS Applications.

Are there any 'gotchas' to using this technique. In the thread I referenced above it's used to buffer incoming binary data without the need for loads of loops going through arrays to manually append data. Will it plant the odd '?' in the stream if it comes upon an invalid DBCS pair ?

Quote:

---

The MidB documentation suggests that the first Argument should be a String

---

you can assign a byte array directly to a string variable and vice versa, but can not concatinate btye arrays, so my guess is the midb (cstr would also work as you are concatinating the the 2 arrays complete) would coerce to a string to concatinate, then the strings are coerced back to byte array, not a very purist way to work with arrays and probably poor for speed, maybe copymemory would be better

Quote:

---

Will it plant the odd '?' in the stream if it comes upon an invalid DBCS pair ?

---

i doubt it, vb strings can contain unicode characters

I don't see any "DBCS hazard" there. MidB (the slow Variant-producing version of the far better MidB$ function) doesn't do any implicit translation between "wide characters" and "multibyte characters" - what we'd do explicitly via StrConv calls.

A BSTR (C/C++ version of a VB String structure) is allowed to have a length of an odd number of bytes. Everything I've found indicates that concatenating two VB Strings containing bytes instead of WCHARs (Windows wide characters, which we'd call Unicode, specifically UTF-16LE) should not go through character encoding conversion either.


However...

I benchmarked this a while back when building a sort of "string builder" or "fast string" class for Byte arrays. MidB$ was pretty slow, and using the sloppy version MidB would be even worse.

Anybody aware enough to use Option Explicit should be savvy enough that the Variant versions of string functions ought to stick out like a sore thumb. Performance isn't always everything but I fail to see very many cases where it isn't worth the effort to type one more character. There are almost no cases where you specifically want a Variant result. Bad habits will kill you later when you do need performance.


Usually when you need this you're far better off using a well-debugged class that uses RTLMoveMemory instead. Trying to review somebody else's code that does stuff like this can take some time, since what they're up and intend doesn't easily jump out at you.

The good news: it is probably safe. Bad news: stinky code.

I posted such a byte buffer class a while back.

Works fine for me, no bugs found since the version I'd posted though feedback is always welcome. I need a tool like this I can trust and though I have a "test suite" to exercise as many things it does as possible you can never be too sure.

BasicBuffer, Binary Stream Class

Works great for things like stream assembly in Winsock control DataArrival event handlers. It has a few "extras" in it for this application to help with protocols where you have a leading Integer or Long "length" header. For Winsock applications it works for output as well, giving you a lightweight way to prefix the length onto an outgoing payload so you can use one .SendData call to blast it out. Handy to avoid extra SendComplete events that might otherwise throw you off.

Quote:

---

Originally Posted by westconn1

...you can assign a byte array directly to a string variable and vice versa....

---

I used VB6 for like a decade and I never knew this. This is just so bad. Years ago this would have been just fine as ANSI character set was fairly standard and ANSI characters are exactly 1 byte wide meaning that it would have been safe to think of characters as interchangeable with bytes. However, in today's unicode world where everyone and their grandmother has invented a different way to encode Unicode code-points, this type of thing would encourage bad practices and wrong ways of thinking that would lead to disaster. I think its wise to stay away from functions like the one posted in the OP unless you're disciplined enough to avoid short-cutting byte array operations by treating them as strings when you're developing your own byte array algorithms.

Character encoding doesn't even come into the picture when you do that. You can operate on straight binary with no issues, no implicit translation gets done.

Apologies, I didn't clarify. I said it would encourage bad practices and wrong ways of thinking. What I was thinking was that people who employ it may take it from VB6 to some other environment where there is no guarantee of no implicit translation. It is not good to think of characters and bytes as interchangeable anymore.

Well, thanks for the Input everyone. I think I undersatnd now