add a single byte to byte()

[David]

Re: add a single byte to byte()

On 2004-09-10, Cor Ligthert <notfirstname@p lanet.nl> wrote:[color=blue]
> David,
>[color=green]
>> Aren't you the one who constantly posts the 80/20 rule here, or am I
>> confusing you with somebody else?[/color]
>
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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]]

Re: add a single byte to byte()

David,[color=blue]
> 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.[/color]
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/architecture/default.aspx?pull=/library/en-us/dnpag/html/scalenet.asp

In addition to the following:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/highperfmanagedapps.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/vbnstrcatn.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchperfopt.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp

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

Hope this helps
Jay


"David" <dfoster@woofix .local.dom> wrote in message
news:slrnck3ve5 .h68.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2004-09-09, Jay B. Harlow [MVP - Outlook] <Jay_Harlow_MVP @msn.com>
> wrote:[color=green]
>> David,[color=darkred]
>>> Aren't you the one who constantly posts the 80/20 rule here, or am I
>>> confusing you with somebody else?[/color]
>>
>> 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".
>>[color=darkred]
>>>> 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.[/color]
>> 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?[/color]
>
> 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.
>[/color]

[David]

Re: add a single byte to byte()

On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Jay_Harlow_MVP @msn.com> wrote:[color=blue]
> David,[color=green]
>> 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.[/color]
> 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.[/color]

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]]

Re: add a single byte to byte()

David,[color=blue]
> So let's make the question more concrete. In the
> real world, how would you approach this problem?[/color]
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.Str ingBuilder 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=ByteBuffer+group:microsoft.public.dotnet.languages.vb&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=8&as_miny=1981&as_maxd=1&as_maxm=8&as_maxy=2003&selm=%23NZTyBGWDHA.1780%40TK2MSFTNGP11.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.
[color=blue]
> d) something else I haven't thought of[/color]
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.
[color=blue]
> 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.[/color]

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" <dfoster@woofix .local.dom> wrote in message
news:slrnck5n5g .hvk.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Jay_Harlow_MVP @msn.com>
> wrote:[color=green]
>> David,[color=darkred]
>>> 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.[/color]
>> 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.[/color]
>
> 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.
>
>
>[/color]

[Cor Ligthert]

Re: add a single byte to byte()

David,
[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
> > However when it should be a bytearray and you do not know the size[/color][/color]
however[color=blue][color=green]
> > 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[/color][/color]
can[color=blue][color=green]
> > earn with that.[/color]
>
> 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.[/color]

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]]

Re: add a single byte to byte()

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" <dfoster@woofix .local.dom> wrote in message
news:slrnck5n5g .hvk.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Jay_Harlow_MVP @msn.com>
> wrote:[color=green]
>> David,[color=darkred]
>>> 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.[/color]
>> 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.[/color]
>
> 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.
>
>
>[/color]

[David]

Re: add a single byte to byte()

On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Jay_Harlow_MVP @msn.com> wrote:[color=blue]
> David,[color=green]
>> So let's make the question more concrete. In the
>> real world, how would you approach this problem?[/color]
> 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)[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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]

Re: add a single byte to byte()

On 2004-09-11, Cor Ligthert <notfirstname@p lanet.nl> wrote:[color=blue]
> David,
>[color=green]
>> 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.[/color]
>
> Why just to disagree,? I real do not see the argument in this.[/color]

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.[color=blue]
>
> 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?[/color]

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]

Re: add a single byte to byte()

On 2004-09-11, Jay B. Harlow [MVP - Outlook] <Jay_Harlow_MVP @msn.com> wrote:[color=blue]
> 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.[/color]

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]

Re: add a single byte to byte()

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]

Re: add a single byte to byte()

On 2004-09-12, Cor Ligthert <notfirstname@p lanet.nl> wrote:[color=blue]
> David,
>
> I putted the "why just disagree" at the wrong text so let that go,[/color]

Okay, as I said I thought it might just be a confusion in my
understanding.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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?
[color=blue]
> This approach will always be with its filledCount right beside the code,[/color]

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[color=blue]
> 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.[/color]

Which is beside the point, since that's precisely the solution you
stated was unnecessary here.[color=blue]
>[/color]

[Cor Ligthert]

Re: add a single byte to byte()

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]

Re: add a single byte to byte()

On 2004-09-12, Cor Ligthert <notfirstname@p lanet.nl> wrote:[color=blue]
> 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?[/color]

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(Ge tType(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.Len gth + 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.
[color=blue]
> Maybe I can than agree better with you.
>
> Cor
>
>[/color]

[Cor Ligthert]

Re: add a single byte to byte()

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]

Re: add a single byte to byte()

On 2004-09-12, Cor Ligthert <notfirstname@p lanet.nl> wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> The boxing time does not interest me, that is about 1/100000000000
> nanosecond[/color]

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,