add a single byte to byte()

[Guoqi Zheng]

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the
value of that individual byte, if that byte is what I want, then I insert it
into the new byte(). How can I do it?

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

[Hal Rosser]

redim the array - and -
assign a byte to the new element

"Guoqi Zheng" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the value of that individual byte, if that byte is what I want, then I insert it into the new byte(). How can I do it?

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.754 / Virus Database: 504 - Release Date: 9/6/2004

[Herfried K. Wagner [MVP]]

* "Hal Rosser" <hm******@bellsouth.net> scripsit:

redim the array - and -
assign a byte to the new element

In this case, 'ReDim Preserve' is the way to go.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[David]

On 2004-09-08, Guoqi Zheng <[e-mail]> wrote:

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the
value of that individual byte, if that byte is what I want, then I insert it
into the new byte(). How can I do it?

For resizable arrays, you really want to use
System.Collections.ArrayList. You can always convert back into an
ordinary byte() after you've filled the ArrayList with the contents you
want.

If you only need to add a single byte one time, then ReDim Preserve will
work fine, but it sounds like you're doing this in a loop, and
performance will be terrible if you rely on ReDim here.

[Hal Rosser]

Agreed

In this case, 'ReDim Preserve' is the way to go.
/>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.754 / Virus Database: 504 - Release Date: 9/7/2004

[Cor Ligthert]

Guaoqi,

Assume you have a text and want it to set as Asci in a byte array, than you
get something as (roughly typed in this message so watch typos)

\\\\
dim myString as string = "Ik hoop dat dit helpt?"
dim ByteArr(mystring.length) as byte
for i as integer = 0 to mystring.length -1
ByteArr(i) = Cbyte(asc(mystrstring.substring(i,1)))
next
///

I hope this helps?

Cor

"Guoqi Zheng"
..

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the value of that individual byte, if that byte is what I want, then I insert it into the new byte(). How can I do it?

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

[Guoqi Zheng]

Thanks, it sounds like exactly what I am looking for. An arraylist then back
to byte()

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com
"David" <df*****@woofix.local.dom> wrote in message
news:slrncjv5fg.aof.df*****@woofix.local.dom...

On 2004-09-08, Guoqi Zheng <[e-mail]> wrote:

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the value of that individual byte, if that byte is what I want, then I insert it into the new byte(). How can I do it?

For resizable arrays, you really want to use
System.Collections.ArrayList. You can always convert back into an
ordinary byte() after you've filled the ArrayList with the contents you
want.

If you only need to add a single byte one time, then ReDim Preserve will
work fine, but it sounds like you're doing this in a loop, and
performance will be terrible if you rely on ReDim here.

[Jay B. Harlow [MVP - Outlook]]

David,
Just be aware that an ArrayList with bytes in it is going to cause a lot of
boxing & unboxing which may hurt performance.

I would consider an array of bytes & ReDim Preserve, only over allocate the
array, then keep track of how many actual elements are in the array. By over
allocate I mean allocate 50 elements in the array although there is only 40
actual elements in it.

I will check if I have a good example. I have posted one or two examples
previously.

Hope this helps
Jay
"David" <df*****@woofix.local.dom> wrote in message
news:slrncjv5fg.aof.df*****@woofix.local.dom...

On 2004-09-08, Guoqi Zheng <[e-mail]> wrote:

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at
the
value of that individual byte, if that byte is what I want, then I insert
it
into the new byte(). How can I do it?

For resizable arrays, you really want to use
System.Collections.ArrayList. You can always convert back into an
ordinary byte() after you've filled the ArrayList with the contents you
want.

If you only need to add a single byte one time, then ReDim Preserve will
work fine, but it sounds like you're doing this in a loop, and
performance will be terrible if you rely on ReDim here.

[Guoqi Zheng]

This solution sounds fine as well.

But if I allocate 500 elements, and I used only 30, how can I remove the
extra 470 from that byte(), by Redim Preserve? and will these extra 470
elements cost performance problem?

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

David,
Just be aware that an ArrayList with bytes in it is going to cause a lot of boxing & unboxing which may hurt performance.

I would consider an array of bytes & ReDim Preserve, only over allocate the array, then keep track of how many actual elements are in the array. By over allocate I mean allocate 50 elements in the array although there is only 40 actual elements in it.

I will check if I have a good example. I have posted one or two examples
previously.

Hope this helps
Jay
"David" <df*****@woofix.local.dom> wrote in message
news:slrncjv5fg.aof.df*****@woofix.local.dom...

On 2004-09-08, Guoqi Zheng <[e-mail]> wrote:

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the
value of that individual byte, if that byte is what I want, then I insert it
into the new byte(). How can I do it?

For resizable arrays, you really want to use
System.Collections.ArrayList. You can always convert back into an
ordinary byte() after you've filled the ArrayList with the contents you
want.

If you only need to add a single byte one time, then ReDim Preserve will
work fine, but it sounds like you're doing this in a loop, and
performance will be terrible if you rely on ReDim here.

[Cor Ligthert]

Jay,

Your answer was my first answer as well, however I scratched it to make an
in my opinion nicer answer.

(I know it is not right to set a unicharacter to an asci value however as
sample goes this so easy)

The way you describe now is also in my opinion the best way to do it when
you do not know the length in advance.

Although an other alternative is of course doing it streaming.

:-)

Cor

David,
Just be aware that an ArrayList with bytes in it is going to cause a lot of boxing & unboxing which may hurt performance.

I would consider an array of bytes & ReDim Preserve, only over allocate the array, then keep track of how many actual elements are in the array. By over allocate I mean allocate 50 elements in the array although there is only 40 actual elements in it.

I will check if I have a good example. I have posted one or two examples
previously.

Hope this helps
Jay
"David" <df*****@woofix.local.dom> wrote in message
news:slrncjv5fg.aof.df*****@woofix.local.dom...

On 2004-09-08, Guoqi Zheng <[e-mail]> wrote:

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the
value of that individual byte, if that byte is what I want, then I insert it
into the new byte(). How can I do it?

For resizable arrays, you really want to use
System.Collections.ArrayList. You can always convert back into an
ordinary byte() after you've filled the ArrayList with the contents you
want.

If you only need to add a single byte one time, then ReDim Preserve will
work fine, but it sounds like you're doing this in a loop, and
performance will be terrible if you rely on ReDim here.

[Jay B. Harlow [MVP - Outlook]]

Guoqi,

extra 470 from that byte(), by Redim Preserve? I would use Redim Preserve, Array.Copy, or Buffer.BlockCopy.
and will these extra 470
elements cost performance problem? 1 allocation of 500 bytes followed by a Redim Preserve is going to perform
better then 30 Redim Preserves. And possible better then 30 boxes & unboxes.
The only real way to tell is to use a profiling tool to check.
Most of the time the overallocating will be the better performing (both
memory usage & speed wise). Sometimes the ArrayList & boxing may perform
acceptable.
Obviously if you know before hand how much space you will need or can make a
very good estimate you have a better chance of it.

Remember that reallocating (Redim preserve) in both cases means that a new
buffer needs to be defined, then the old buffer needs to be copied to the
new array.

Hope this helps
Jay
"Guoqi Zheng" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... This solution sounds fine as well.

But if I allocate 500 elements, and I used only 30, how can I remove the
extra 470 from that byte(), by Redim Preserve? and will these extra 470
elements cost performance problem?

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

David,
Just be aware that an ArrayList with bytes in it is going to cause a lot

of

boxing & unboxing which may hurt performance.

I would consider an array of bytes & ReDim Preserve, only over allocate

the

array, then keep track of how many actual elements are in the array. By

over

allocate I mean allocate 50 elements in the array although there is only

40

actual elements in it.

I will check if I have a good example. I have posted one or two examples
previously.

Hope this helps
Jay
"David" <df*****@woofix.local.dom> wrote in message
news:slrncjv5fg.aof.df*****@woofix.local.dom...

> On 2004-09-08, Guoqi Zheng <[e-mail]> wrote:
>> I am really do not know so much about byte/bit, etc.
>>
>> Question, if I defined a byte(), how can I add a single byte to it?
>>
>> what I want is that I have an array of bytes, I loop that array, look at >> the
>> value of that individual byte, if that byte is what I want, then I insert >> it
>> into the new byte(). How can I do it?
>
> For resizable arrays, you really want to use
> System.Collections.ArrayList. You can always convert back into an
> ordinary byte() after you've filled the ArrayList with the contents you
> want.
>
> If you only need to add a single byte one time, then ReDim Preserve
> will
> work fine, but it sounds like you're doing this in a loop, and
> performance will be terrible if you rely on ReDim here.
>
>

[David]

On 2004-09-09, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote:

David,
Just be aware that an ArrayList with bytes in it is going to cause a lot of
boxing & unboxing which may hurt performance.

Actually, it wouldn't cause a lot of either, just once per byte, which
is trivial unless you're dealing with huge nested loops. Overallocating
an array is faster, but unless you are absolutely sure you'll never need
a larger array (and that might be the case here), what should be a very
simple loop starts looking much uglier than it needs to be.

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?

[Jay B. Harlow [MVP - Outlook]]

David,

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?
Yes I am. Which is why I stated "may hurt performance", then again today I
added to "the only real way to tell is to use a profiling tool to check".

Just be aware that an ArrayList with bytes in it is going to cause a lot
of
boxing & unboxing which may hurt performance.

Actually, it wouldn't cause a lot of either, just once per byte, which
is trivial unless you're dealing with huge nested loops.

Correct. You will have a box for each byte you put into the ArrayList. Plus
an Unbox for each byte you remove.

So if you have a lot of bytes you will have a lot of boxing. In other words
at least 1 box & unbox for each byte. Correct?

Hope this helps
Jay

"David" <df*****@woofix.local.dom> wrote in message
news:slrnck1ivm.dal.df*****@woofix.local.dom... On 2004-09-09, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com>
wrote:

David,
Just be aware that an ArrayList with bytes in it is going to cause a lot
of
boxing & unboxing which may hurt performance.

Actually, it wouldn't cause a lot of either, just once per byte, which
is trivial unless you're dealing with huge nested loops. Overallocating
an array is faster, but unless you are absolutely sure you'll never need
a larger array (and that might be the case here), what should be a very
simple loop starts looking much uglier than it needs to be.

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?

[Cor Ligthert]

David,

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?

And the other one in other words is me. I am the one who uses almost the
arraylist in samples for everything while others point mostly than too the
hashtable, (where I use than when it is needed earlier the sortedlist).

When it is about a byte array, than there should be a reason why it is a
byte array, because it is in my opinion an archaic piece of storage, altough
very good for serializing and deserializing. For those you loads the
bytearray streaming and you do not need to set a byte by byte to an array.

You can see in this thread a message from me which describes a bytearray
with ASCI chareacter, however for what I would directly use an arraylist
when it was really needed to get the full unicode in a char. (Although I
really cannot find a reason for that)

In my idea in this case when there is really a bytearray needed, than we
should never go to the arraylist, because than the one who does that has
never investigated his problem. Because the byte is the value type you take
as last to choose from when it is not streaming.

However when it should be a bytearray and you do not know the size however
know that the maximum is 400bytes, than you should not even redim it.
Probably you will loose with the code to redim more bytes than what you can
earn with that.

However just my idea.

Cor

[David]

On 2004-09-09, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote:

David,

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?

Yes I am. Which is why I stated "may hurt performance", then again today I
added to "the only real way to tell is to use a profiling tool to check".

Just be aware that an ArrayList with bytes in it is going to cause a lot
of
boxing & unboxing which may hurt performance.

Actually, it wouldn't cause a lot of either, just once per byte, which
is trivial unless you're dealing with huge nested loops.

Correct. You will have a box for each byte you put into the ArrayList. Plus
an Unbox for each byte you remove.

So if you have a lot of bytes you will have a lot of boxing. In other words
at least 1 box & unbox for each byte. Correct?

Yep, it increases O(n) as the number of bytes increases. It's a rare
app where such a thing is a major concern. Though, certainly, such apps
are out there.

[David]

On 2004-09-10, Cor Ligthert <no**********@planet.nl> wrote:

David,

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?
And the other one in other words is me. I am the one who uses almost the
arraylist in samples for everything while others point mostly than too the
hashtable, (where I use than when it is needed earlier the sortedlist).

When it is about a byte array, than there should be a reason why it is a
byte array, because it is in my opinion an archaic piece of storage, altough
very good for serializing and deserializing. For those you loads the
bytearray streaming and you do not need to set a byte by byte to an array.

You can see in this thread a message from me which describes a bytearray
with ASCI chareacter, however for what I would directly use an arraylist
when it was really needed to get the full unicode in a char. (Although I
really cannot find a reason for that)

In my idea in this case when there is really a bytearray needed, than we
should never go to the arraylist, because than the one who does that has
never investigated his problem. Because the byte is the value type you take
as last to choose from when it is not streaming.

OK, I'm honestly not sure if I'm understanding this correctly, but...

I don't see your reasoning here, largely because you don't seem to have
any. The issue is that you need to accumulate bytes, regardless of
where they're coming from (so streaming or not isn't really relevant).
Why do you think an arraylist shouldn't be used for accumulation here?
You state this as an absolute ("one who does that has never
investigated"), but never say why. If it's the performance issue, I'd
suggest that your concerns are misplaced, since it's highly unlikely the
performance hit is going to be noticeable.
However when it should be a bytearray and you do not know the size however
know that the maximum is 400bytes, than you should not even redim it.
Probably you will loose with the code to redim more bytes than what you can
earn with that.

OK, now that I understand, and disagree with completely. Passing around
an incomplete array, one whose length is not the same as the number of
valid entries, is a recipe for disaster. Sure, you'll remember what's
going on while you write this code, but six months later it's incredibly
easy to forget that you've got some other variable someplace telling you
what the "real length" of the array is.

This is the sort of premature optimization that the 80/20 rule is meant
to address. This suggested "fix" would greatly harm readability, and
add to performance only slightly, and I'd profile the hell out of an app
before I went that direction.

[Jay B. Harlow [MVP - Outlook]]

David,

Yep, it increases O(n) as the number of bytes increases. It's a rare
app where such a thing is a major concern. Though, certainly, such apps
are out there. I question where you get "rare app" from! :-|

If the OPs function is being used regularly in a ASP.NET app I could see it
adversely effecting performance, as all those boxed bytes need to be GCed,
which increases the time spent in the GC. In addition to the increased time
the client may see waiting for the response itself from being processed...

ASP.NET apps are far from rare.

Of course one would really need to use tools such as ACT & CLR Profiler to
accurately determine if the boxed bytes were causing a problem or not.
Rather then using conjecture to suggest they do or do not. Hence "may hurt
performance" in my original comments, which I'm sure you will agree implies
may not.

My suggestion of avoiding the boxing altogether, if needed, is based on
reading the following:

http://msdn.microsoft.com/architectu...l/scalenet.asp

In addition to the following:

http://msdn.microsoft.com/library/de...anagedcode.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

http://msdn.microsoft.com/library/de...vbnstrcatn.asp

http://msdn.microsoft.com/library/de...tchperfopt.asp

http://msdn.microsoft.com/library/de...tperftechs.asp

All of which describe methods of writing code that performs well.

Hope this helps
Jay
"David" <df*****@woofix.local.dom> wrote in message
news:slrnck3ve5.h68.df*****@woofix.local.dom... On 2004-09-09, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com>
wrote:

David,

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?

Yes I am. Which is why I stated "may hurt performance", then again today
I
added to "the only real way to tell is to use a profiling tool to check".

Just be aware that an ArrayList with bytes in it is going to cause a
lot
of
boxing & unboxing which may hurt performance.

Actually, it wouldn't cause a lot of either, just once per byte, which
is trivial unless you're dealing with huge nested loops.

Correct. You will have a box for each byte you put into the ArrayList.
Plus
an Unbox for each byte you remove.

So if you have a lot of bytes you will have a lot of boxing. In other
words
at least 1 box & unbox for each byte. Correct?

Yep, it increases O(n) as the number of bytes increases. It's a rare
app where such a thing is a major concern. Though, certainly, such apps
are out there.

[David]

On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote:

David,

Yep, it increases O(n) as the number of bytes increases. It's a rare
app where such a thing is a major concern. Though, certainly, such apps
are out there.

I question where you get "rare app" from! :-|

If the OPs function is being used regularly in a ASP.NET app I could see it
adversely effecting performance, as all those boxed bytes need to be GCed,
which increases the time spent in the GC. In addition to the increased time
the client may see waiting for the response itself from being processed...

ASP.NET apps are far from rare.

Of course one would really need to use tools such as ACT & CLR Profiler to
accurately determine if the boxed bytes were causing a problem or not.
Rather then using conjecture to suggest they do or do not. Hence "may hurt
performance" in my original comments, which I'm sure you will agree implies
may not.

It's interesting that we don't seem to be disagreeing on anything
concrete here, just using different language that implies a different
level of concern. So let's make the question more concrete. In the
real world, how would you approach this problem? I'm really not quite
getting that precisely that from your comments (nor from mine, I'd add),
and that's the question that's actually interesting here.

Let's assume that this isn't the core function of the entire app, just
that on a few pages you need to filter input of unknown size (say
something uploaded from the user) and pass a byte array to another
assembly.

Do you
a) implement with array+fixup
b) implement with ArrayList, changing to array at a later
development cycle only if profiling suggests it
c) profile immediately to see the difference
d) something else I haven't thought of

In the real world, I'd almost definitely implement originally with
boxing. I very seldom declare arraylists, so I'd be using
CollectionBase, but it's the same concept. Then I'd switch to an array
implementation only if profiling during a later cycle suggested it.

Also, I'd probably switch to an array implementation inside the
collection class if I called the byte accumulation code from three or
more places, and to be honest I'd switch without profiling. That's evil
and wrong, but I'm being honest here. (Hopefully I'd have forced a
capacity parameter to the collection constructor, but I'd probably
forget).

There's two things I wouldn't do. I wouldn't profile immediately unless
this functionality was the absolutely primary action during multiple
responses. The profiler just isn't part of my day-to-day toolset. Also,
I would never implement with array fixup inside the loop or surrounding
the loop. I find array declarations to be far too error prone for that.

The interesting questions usually aren't "how do you do X", folks can
look that stuff up. What's interesting to me is "how do you approach
problem X"; how does one actually deal with these issues in day-to-day
work.

[Jay B. Harlow [MVP - Outlook]]

David,

So let's make the question more concrete. In the
real world, how would you approach this problem? Unfortunately there is no where near enough information (here) to make an
informed decision on it. Hence my statement "may hurt performance" so the OP
could weigh the options on his actual requirements and make an informed
decision. Which via profiling may need to be changed.

If it was the core function of that class (UUENCODE class) I would probably
use the ByteBuffer class I started earlier, ByteBuffer functions very
similar to the System.Text.StringBuilder class in that it maintains a byte
array internally allowing you to append bytes or byte arrays on the end,
expanding the internal array as needed.

http://groups.google.com/groups?q=By...phx.gbl&rnum=3

I would be choosing ByteBuffer for exactly the same reason I would choose
StringBuilder or ArrayList.

Notice that the UUENCODE class itself doesn't use any of the methods you
identified per se, however the ByteBuffer class itself does (encapsulation,
reuse).

Another factor I would consider before I actually decided which method to
use first (pre-profiling) would be how large a buffer I would normally work
with, and how often it changed.

For example, if I knew I would always need a fixed size buffer (based on the
length of an input string for example) and no reallocations were needed,
then obviously this discussion is moot. Or if I knew I could use a slightly
larger buffer, with a little slack, with a single reallocation at the end,
then a simple array would do.

There may be other considerations in the OPs needs that I don't have right
now...

Again it really would depend on the complete real requirements of the
problem.
d) something else I haven't thought of Thinking about it, I would consider using a MemoryStream also, as it
effectively is an ArrayList or StringBuilder for bytes. In other words a
dynamic array of bytes, without the boxing.
In the real world, I'd almost definitely implement originally with
boxing. I very seldom declare arraylists, so I'd be using
CollectionBase, but it's the same concept. Then I'd switch to an array
implementation only if profiling during a later cycle suggested it.
Using a CollectionBase does not feel right here, as the buffer in question
seems like an implementation detail of the UUENCODE functionality, not a
collection of domain objects per se. I normally reserve CollectionBase
classes for collections of domain objects. FWIW a Domain object is the more
general term for business object.

Unless you were suggesting you would inherit from CollectionBase to
implement a ByteBuffer class.

Of course when we get to VB.NET 2005 (Whidbey due out in 2005), Using a
generic byte list would be an option also
(http://msdn2.microsoft.com/library/6sh2ey19.aspx).

Hope this helps
Jay

"David" <df*****@woofix.local.dom> wrote in message
news:slrnck5n5g.hvk.df*****@woofix.local.dom... On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com>
wrote:

David,

Yep, it increases O(n) as the number of bytes increases. It's a rare
app where such a thing is a major concern. Though, certainly, such apps
are out there.

I question where you get "rare app" from! :-|

If the OPs function is being used regularly in a ASP.NET app I could see
it
adversely effecting performance, as all those boxed bytes need to be
GCed,
which increases the time spent in the GC. In addition to the increased
time
the client may see waiting for the response itself from being
processed...

ASP.NET apps are far from rare.

Of course one would really need to use tools such as ACT & CLR Profiler
to
accurately determine if the boxed bytes were causing a problem or not.
Rather then using conjecture to suggest they do or do not. Hence "may
hurt
performance" in my original comments, which I'm sure you will agree
implies
may not.

It's interesting that we don't seem to be disagreeing on anything
concrete here, just using different language that implies a different
level of concern. So let's make the question more concrete. In the
real world, how would you approach this problem? I'm really not quite
getting that precisely that from your comments (nor from mine, I'd add),
and that's the question that's actually interesting here.

Let's assume that this isn't the core function of the entire app, just
that on a few pages you need to filter input of unknown size (say
something uploaded from the user) and pass a byte array to another
assembly.

Do you
a) implement with array+fixup
b) implement with ArrayList, changing to array at a later
development cycle only if profiling suggests it
c) profile immediately to see the difference
d) something else I haven't thought of

In the real world, I'd almost definitely implement originally with
boxing. I very seldom declare arraylists, so I'd be using
CollectionBase, but it's the same concept. Then I'd switch to an array
implementation only if profiling during a later cycle suggested it.

Also, I'd probably switch to an array implementation inside the
collection class if I called the byte accumulation code from three or
more places, and to be honest I'd switch without profiling. That's evil
and wrong, but I'm being honest here. (Hopefully I'd have forced a
capacity parameter to the collection constructor, but I'd probably
forget).

There's two things I wouldn't do. I wouldn't profile immediately unless
this functionality was the absolutely primary action during multiple
responses. The profiler just isn't part of my day-to-day toolset. Also,
I would never implement with array fixup inside the loop or surrounding
the loop. I find array declarations to be far too error prone for that.

The interesting questions usually aren't "how do you do X", folks can
look that stuff up. What's interesting to me is "how do you approach
problem X"; how does one actually deal with these issues in day-to-day
work.

[Cor Ligthert]

David,

I don't see your reasoning here, largely because you don't seem to have
any. The issue is that you need to accumulate bytes, regardless of
where they're coming from (so streaming or not isn't really relevant).
Why do you think an arraylist shouldn't be used for accumulation here?
You state this as an absolute ("one who does that has never
investigated"), but never say why. If it's the performance issue, I'd
suggest that your concerns are misplaced, since it's highly unlikely the
performance hit is going to be noticeable.

An arraylist is not made to simulate a bytearray simple. (A bytearray is a
concatenated string of bytes), I do not use a mouse to type either, while it
is not imposible when I first draw a keybord on my screen.

However when it should be a bytearray and you do not know the size however know that the maximum is 400bytes, than you should not even redim it.
Probably you will loose with the code to redim more bytes than what you can earn with that.

OK, now that I understand, and disagree with completely. Passing around
an incomplete array, one whose length is not the same as the number of
valid entries, is a recipe for disaster. Sure, you'll remember what's
going on while you write this code, but six months later it's incredibly
easy to forget that you've got some other variable someplace telling you
what the "real length" of the array is.

Why just to disagree,? I real do not see the argument in this.

You will use a long, an integer, a double, a variable lenght string, however
a byte array of 400 bytes becomes to much for you?

Cor

[Jay B. Harlow [MVP - Outlook]]

David,
I should add:

Another consideration I would consider is how large a buffer are we talking,
if it appeared the buffer was going to from 1 to maybe 20 bytes (based on
the requirements), then I would be less likely not to use the ArrayList.
However if it appeared to be from 100 to 250 bytes+ then I would consider
the ByteBuffer more.

It would depend on how "smelly" the code felt. (Smelly code is a Refactoring
term (http://www.refactoring.com)

Hope this helps
Jay
"David" <df*****@woofix.local.dom> wrote in message
news:slrnck5n5g.hvk.df*****@woofix.local.dom...

On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com>
wrote:

David,

Yep, it increases O(n) as the number of bytes increases. It's a rare
app where such a thing is a major concern. Though, certainly, such apps
are out there.

I question where you get "rare app" from! :-|

If the OPs function is being used regularly in a ASP.NET app I could see
it
adversely effecting performance, as all those boxed bytes need to be
GCed,
which increases the time spent in the GC. In addition to the increased
time
the client may see waiting for the response itself from being
processed...

ASP.NET apps are far from rare.

Of course one would really need to use tools such as ACT & CLR Profiler
to
accurately determine if the boxed bytes were causing a problem or not.
Rather then using conjecture to suggest they do or do not. Hence "may
hurt
performance" in my original comments, which I'm sure you will agree
implies
may not.

It's interesting that we don't seem to be disagreeing on anything
concrete here, just using different language that implies a different
level of concern. So let's make the question more concrete. In the
real world, how would you approach this problem? I'm really not quite
getting that precisely that from your comments (nor from mine, I'd add),
and that's the question that's actually interesting here.

Let's assume that this isn't the core function of the entire app, just
that on a few pages you need to filter input of unknown size (say
something uploaded from the user) and pass a byte array to another
assembly.

Do you
a) implement with array+fixup
b) implement with ArrayList, changing to array at a later
development cycle only if profiling suggests it
c) profile immediately to see the difference
d) something else I haven't thought of

In the real world, I'd almost definitely implement originally with
boxing. I very seldom declare arraylists, so I'd be using
CollectionBase, but it's the same concept. Then I'd switch to an array
implementation only if profiling during a later cycle suggested it.

Also, I'd probably switch to an array implementation inside the
collection class if I called the byte accumulation code from three or
more places, and to be honest I'd switch without profiling. That's evil
and wrong, but I'm being honest here. (Hopefully I'd have forced a
capacity parameter to the collection constructor, but I'd probably
forget).

There's two things I wouldn't do. I wouldn't profile immediately unless
this functionality was the absolutely primary action during multiple
responses. The profiler just isn't part of my day-to-day toolset. Also,
I would never implement with array fixup inside the loop or surrounding
the loop. I find array declarations to be far too error prone for that.

The interesting questions usually aren't "how do you do X", folks can
look that stuff up. What's interesting to me is "how do you approach
problem X"; how does one actually deal with these issues in day-to-day
work.

[David]

On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote:

David,

So let's make the question more concrete. In the
real world, how would you approach this problem?

Unfortunately there is no where near enough information (here) to make an
informed decision on it. Hence my statement "may hurt performance" so the OP
could weigh the options on his actual requirements and make an informed
decision. Which via profiling may need to be changed.\

If it was the core function of that class (UUENCODE class)

Obviously there's not enough info here (we have almost no info at all),
but that's why I added to the hypothetical, and specifically asked about
the situation where it *wasn't* the core function. If it's a very
important operation that's used a lot, I think we'd all spend a little
more time on it and get a fairly robust solution. I don't think anybody
disagrees with that, or with the general nature of that solution.

What I was really interested in was what people's approaches would be if
it were just an ordinary work-a-day question, the kind of thing that
pops up a dozen times a day. But hypotheticals of this sort always
leave a lot of ambiguity since there's so many unknown variables
involved, so I admit that's not an easily answered question.

In the real world, I'd almost definitely implement originally with
boxing. I very seldom declare arraylists, so I'd be using
CollectionBase, but it's the same concept. Then I'd switch to an array
implementation only if profiling during a later cycle suggested it.

Using a CollectionBase does not feel right here, as the buffer in question
seems like an implementation detail of the UUENCODE functionality, not a
collection of domain objects per se. I normally reserve CollectionBase
classes for collections of domain objects. FWIW a Domain object is the more
general term for business object.

Unless you were suggesting you would inherit from CollectionBase to
implement a ByteBuffer class.

Partially. As I said, I very seldom declare ArrayLists, I reach for a
typed collection almost immediately, and my standard script creates one
derived from CollectionBase. I was trying to describe the situation
where this function looked as if it would be little used, and I just
wanted to get the loop working quickly.

[David]

On 2004-09-11, Cor Ligthert <no**********@planet.nl> wrote:

David,

OK, now that I understand, and disagree with completely. Passing around
an incomplete array, one whose length is not the same as the number of
valid entries, is a recipe for disaster. Sure, you'll remember what's
going on while you write this code, but six months later it's incredibly
easy to forget that you've got some other variable someplace telling you
what the "real length" of the array is.
Why just to disagree,? I real do not see the argument in this.

This might be the language thing, but "just to disagree" to me implies
I'm being disingenuous or argumentative for argument's sake. If so, I
assure you I'm not. I really do disagree here.
You will use a long, an integer, a double, a variable lenght string, however
a byte array of 400 bytes becomes to much for you?

Long, integers and doubles are individual entities. A string object
maintains its own length. And yes, a byte array of any size where the
"true" length of the array is kept separately is too much for me.

If I absolutely had to do this for performance' sake, I'd immediately
encapsulate it into its own class that did very little except keep track
of the byte length, and I'd test it to death before I felt even a little
comfortable.

It all has to do with how much complexity you're willing to allow in
your programs. Hopefully you can agree that an array that does not
contain Array.Length objects is more complex than a completely filled
array. To me, it's too complex to exist for long inside a function, and
*way* too complex to pass around between functions.

[David]

On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote:

David,
I should add:

Another consideration I would consider is how large a buffer are we talking,
if it appeared the buffer was going to from 1 to maybe 20 bytes (based on
the requirements), then I would be less likely not to use the ArrayList.
However if it appeared to be from 100 to 250 bytes+ then I would consider
the ByteBuffer more.

I wouldn't disagree, though it all depends on the centrality of this
operation of course, as you say. This paragraph implies that you would
never use the inline array solution, which is actually the question I
was getting at. What I was really curious about when I posed the
hypothetical was whether the folks in this thread would really reach for
the "fix the array inside the loop" solution which many were suggesting.

[Cor Ligthert]

David,

I putted the "why just disagree" at the wrong text so let that go, it is to
difficult to remake the starting point of that text while the arguing is now
more about an incomplete bytearray.

Your point is that in can confuse. However maybe that is because you are
never using it. That is always with making programs, when you have taken an
approach you know what you are doing, for strangers it can look strange.

This approach will always be with its filledCount right beside the code, the
same as the redim will be beside its code, and the arraylist.count has the
code always used in the code. When it real should be a point you can even
make your own class for it, with your own "populatedcount" property for
that.

Cor

[David]

On 2004-09-12, Cor Ligthert <no**********@planet.nl> wrote:

David,

I putted the "why just disagree" at the wrong text so let that go,
Okay, as I said I thought it might just be a confusion in my
understanding.
it is to
difficult to remake the starting point of that text while the arguing is now
more about an incomplete bytearray.

Your point is that in can confuse.
Not entirely, and your reduction of my post to that leads to your error
below. My point isn't just that the code can confuse, as you say any
code can be confusing if you've never worked in that field before or if
you aren't used to a specific pattern or style.

My point was that the confusion here stems from additional code
complexity. There isn't anything here that I would assume a decent
programmer isn't familiar with. Arrays, loops, indexes and the ReDim
statement are things I assume every decent programmer can handle easily.
However maybe that is because you are
never using it. That is always with making programs, when you have taken an
approach you know what you are doing, for strangers it can look strange.
Are you suggesting you *often* do this? Familiarity leads me to the
assumption that Array.Length is valid as the count of entries. Are you
suggesting that if I read a lot of your code I'd start to assume
otherwise?
This approach will always be with its filledCount right beside the code,
Which isn't close enough for me, especially when you've got another
property right beside the code that usually refers to the same thing
(i.e., Array.Length). Look, go ahead and disagree, that's fine. As I
said originally, the level of complexity people allow in their code
differs tremendously. But I don't think one can seriously contend
there's not a complexity issue here.
the same as the redim will be beside its code, and the arraylist.count has the
code always used in the code. When it real should be a point you can even
make your own class for it, with your own "populatedcount" property for
that.
Which is beside the point, since that's precisely the solution you
stated was unnecessary here.

[Cor Ligthert]

David,

Because I have made so many samples for the bytearray in this situation, I
want to turn it around, give me one practical sample where adding a byte to
an arraylist would be a right solution.

So not that you can add a byte to an arraylist, I know I can do that (you
can add any object to a arraylist), however for what situation would it be a
practical solution?

Maybe I can than agree better with you.

Cor

[David]

On 2004-09-12, Cor Ligthert <no**********@planet.nl> wrote:

David,

Because I have made so many samples for the bytearray in this situation, I
want to turn it around, give me one practical sample where adding a byte to
an arraylist would be a right solution.

So not that you can add a byte to an arraylist, I know I can do that (you
can add any object to a arraylist), however for what situation would it be a
practical solution?
OK, you've got some kind of code reader that sends a stream of bytes to
you, but the verification program (named Foo, naturally) you have only
wants bytes with the upper bit unset.

Private Sub VerifyWithList(ByVal stm As Stream)
Dim list As New ArrayList

Dim input As Integer
Do
input = stm.ReadByte()
If input = -1 Then Exit Do

If input >= 0 AndAlso input <= 127 Then
list.Add(CByte(input))
End If
Loop

Foo(DirectCast(list.ToArray(GetType(Byte)), Byte()))

End Sub

Now, as I mentioned, I tend to use typed collections, so the cast at the
end would go away (which is by far the most complex line), but otherwise
this is probably my first implementation. The two things that leap out
are (a) I'm not thrilled about the way I'm reading the stream here, and
(b) the infinite loop might throw some programmers for a moment, but I
think it's the cleanest implementation (see McConnell's Code Complete
for reams of discussion about formatting this type of loop), but if
someone in code review insisted I be more explicit here I wouldn't
argue.

Here's the function I wouldn't write:

Private Sub Verify(ByVal stm As Stream)
Dim bytes(ESTIMATED) As Byte
Dim index As Integer = 0
Dim input As Integer

Do
input = stm.ReadByte()
If input = -1 Then Exit Do

If input >= 0 AndAlso input <= 127 Then
If index > bytes.Length Then
ReDim Preserve bytes(bytes.Length + ESTIMATED)
End If
bytes(index) = CByte(input)
index += 1
End If
Loop

ReDim Preserve bytes(index - 1)

Foo(bytes)

End Sub

Just to be honest here, I'm posting this as I really did first write it.
And sure enough, it has a bug. The first function is trivial to write
and easy to read. The second function is much trickier. A bug in the
first function would leap out at you at a glance, the bug in the second
function isn't easy to see without looking fairly closely at the code.

And what I absolutely would never do is finish the above like this:

Foo(bytes, index-1)

' while I define Foo as

Public Sub Foo(bytes() as Byte, validBytes as Integer)


One additional point. Jay pretty much had me convinced that I should
worry about boxing much earlier than I tend to. But I can't even
measure the different in timespans that the above two functions take to
run (not with a DateTime object anyway, the noise overwhelms the
difference), even as the array grows to thousands of bytes. That
surprised me, I admit.
Maybe I can than agree better with you.

Cor

[Cor Ligthert]

David,

I know how to do it, my problem for this is that I cannot find a practical
solution for this with an arraylist.

A situation where I would have to add 1 byte to a byte array byte by byte,
while I do not know the length of that bytestring.

The boxing time does not interest me, that is about 1/100000000000
nanosecond

Cor

[David]

On 2004-09-12, Cor Ligthert <no**********@planet.nl> wrote:

David,

I know how to do it, my problem for this is that I cannot find a practical
solution for this with an arraylist.

A situation where I would have to add 1 byte to a byte array byte by byte,
while I do not know the length of that bytestring.
Okay, this is the third time in a row where you've asked a question,
I've followed up with a fairly specific response that raised specific
issues and asked specific questions, and you've totally ignored my
response and followed up with a non-sequitor. There's really very
little point in continuing the thread.
The boxing time does not interest me, that is about 1/100000000000
nanosecond

This is the kind of thing I mean. I honestly have absolutely no clue
what your point is here. If boxing isn't the issue, I have no idea what
your objection to an arrayList would be, nor do I expect to find out.

Cheers,

[Cor Ligthert]

David,

You just avoiding the answers in my opinion by giving answers on not asked
questions.

I write it again in another way.

Where can I use the arraylist when I have populated that with objects with
single bytes in that.

I have nowhere spoken about boxing, boxing does really not interest me with
an array of 400 bytes.

Cor

On 2004-09-12, Cor Ligthert <no**********@planet.nl> wrote:

David,

I know how to do it, my problem for this is that I cannot find a practical solution for this with an arraylist.

A situation where I would have to add 1 byte to a byte array byte by byte, while I do not know the length of that bytestring.

Okay, this is the third time in a row where you've asked a question,
I've followed up with a fairly specific response that raised specific
issues and asked specific questions, and you've totally ignored my
response and followed up with a non-sequitor. There's really very
little point in continuing the thread.

The boxing time does not interest me, that is about 1/100000000000
nanosecond

This is the kind of thing I mean. I honestly have absolutely no clue
what your point is here. If boxing isn't the issue, I have no idea what
your objection to an arrayList would be, nor do I expect to find out.

Cheers,

[David]

On 2004-09-13, Cor Ligthert <no**********@planet.nl> wrote:

David,

You just avoiding the answers in my opinion by giving answers on not asked
questions.

I write it again in another way.

Where can I use the arraylist when I have populated that with objects with
single bytes in that.
Go back two posts. Read the post. I have two functions there. Read
them, and the surrounding text. You asked for an example. There's an
example there, as well as two counter-examples.
I have nowhere spoken about boxing, boxing does really not interest me with
an array of 400 bytes.

The issue is how to create that array.

[Cor Ligthert]

David,

OK, you've got some kind of code reader that sends a stream of bytes to
you, but the verification program (named Foo, naturally) you have only
wants bytes with the upper bit unset.

Why would I do that, that is what I am al the time asking?

Creating an not organised array of bytes?

Cor