[VB] Queue

[Noodlez]

Here is a simple queue class I wrote after reading an article at aihorizons.com (and looking at the C++ code for it)

This is not a normal queue, however... think of it as a line for a ride, except instead of everyone stepping forwards, they step backwards, then eventually wrap back around to the front. This is a much faster method then making everyone step forward.

Code Select Expand


Private lngStart As Long
Private lngEnd As Long
Private lngElemCount As Long
Private lngData() As String

Private Const MaxNum As Long = 50

Public Sub Enequeue(text As String)
   If lngElemCount < MaxNum Then
       lngEnd = lngEnd + 1
       lngData(lngEnd) = text
       lngElemCount = lngElemCount + 1
       If lngEnd > MaxNum Then
           lngEnd = lngEnd - MaxNum + 1
       End If
   End If
End Sub
Public Function Dequeue() As String
   If lngElemCount > 0 Then
       lngStart = lngStart + 1
       Dequeue = lngData(lngStart)
       elemcount = elemcount - 1
       If lngStart > MaxNum Then
           lngStart = lngStart - MaxNum + 1
       End If
   End If
End Function
Private Sub Class_Initialize()
   lngStart = 0
   lngEnd = 0
   lngElemCount = 0
   ReDim lngData(MaxNum + 1)
End Sub

Private Sub Class_Terminate()
   Erase lngData
End Sub

Enjoy

corrections welcome

[TheMinistered]

Noodlez, why not just use a collection?

[dxoigmn]

Noodlez, why not just use a collection?

Because collections are slow and speed matters in Visual Basic!!  

[Camel]

Isn't the point of a queue to slow down the sending of text as to not flood off battle.net?

[dxoigmn]

Isn't the point of a queue to slow down the sending of text as to not flood off battle.net?

Yes, but who said this has anything to do with Battle.net?

[TheMinistered]

I'm willing to bet a implementation using collections will be just as fast if not faster and easier to code + use.

[dxoigmn]

I'm willing to bet a implementation using collections will be just as fast if not faster and easier to code + use.

I'll take that bet, provided you use VB's built-in collection object and not some custom collection object.

Edit:  collections are slow depending on the operation use (i.e. Add, Remove, Insert, Item by Key/Index) and in this instance I think Array's would be faster.

Edit 2: Feel feel to prove me wrong though.

[Eibro]

Isn't the point of a queue to slow down the sending of text as to not flood off battle.net?

You'd want a controlled flow, not one that's dictated by sluggish code.

[TheMinistered]

His is a fixed queue + it returns absolutely no error information.

Code Select Expand


Public Sub Enequeue(ByVal text As String, ByRef return as Byte)
   If lngElemCount < MaxNum Then
       lngEnd = lngEnd + 1
       lngData(lngEnd) = text
       lngElemCount = lngElemCount + 1
       If lngEnd > MaxNum Then
           lngEnd = lngEnd - MaxNum + 1
       End If
   Else
       return = -1
   End If
End Sub


or, you could use a function and return a value. You, however, might be right about his being faster than the built in collection object.  I don't know, I was just making assumptions based on a little experience.  

[Camel]

Isn't the point of a queue to slow down the sending of text as to not flood off battle.net?

You'd want a controlled flow, not one that's dictated by sluggish code.

My point is that as long as the code isn't painfully slow/time critical, slightly sluggish code is sometimes better than spending a week writing efficient code (NOTE: sluggish != sloppy, efficent != neat). If the objective is to wait a set ammount of time, must it be exactly accurate? If so, one must ask himself why he is using VB in the first place, no? Am I wrong in saying that the point of VB is to ease development at the cost of efficiency and, sometimes, power?

[Noodlez]

Ministered: I'm not using collections because this is faster.

Camel: Sure, when you use VB your knownignly sacrificing those things, however, that doesn't mean you can't still try your best to optimize your program and use VB to the fullest exent. Another thing, writing effecient code doesn't take "weeks" as you put it... if you know what you're doing, it can be done in just as much time, maybe a little slower; but the end product is worth it.

Let's say your commericialy programming, your client want's you to use VB, however he also asked that the code be fast and small; this is when that would come in.

And btw, a queue doesn't only have to be used for BNet. You could modify the datatype to a long and instead give it AddressOf(Function) and queue your functions!


Here is a better explanation of why this is faster.
In a standard queue, you add items, and the first item in is the first one out (first in first out, FIFO). After taking the first item out, you must move all the items before it up one step. However, with this method, all that is being changed is the position in which the item come's out from and wraps around newly added data.

Real example:
FIFO

Code Select Expand


X 2 3 4
X 3 4
X 4
X

Circular Method

Code Select Expand


X 2 3 4
0 X 3 4
0 0 X 4
0 0 0 X


[TheMinistered]

Your example is poor, try again.

[Grok]

My point is that as long as the code isn't painfully slow/time critical, slightly sluggish code is sometimes better than spending a week writing efficient code (NOTE: sluggish != sloppy, efficent != neat). If the objective is to wait a set ammount of time, must it be exactly accurate? If so, one must ask himself why he is using VB in the first place, no? Am I wrong in saying that the point of VB is to ease development at the cost of efficiency and, sometimes, power?

There's nothing wrong with trying to do the best possible job with design patterns, and a particular tool's idioms.

In the book "The Practice of Programming", author Brian Kernighan proposes that programming languages have "idioms" -- conventions that experienced developers use to build common coding elements.  These are similar to design patterns, but are finer in granularity.  Idioms are more generic than design patterns.  They have more to do with the language than with solving a particular type of problem.

In the book "Design Patterns", author Erich Gamma propose that there are certain patterns in software design that expert developers regularly use and recognize in code written by others.  The book seeks to formally catalog these patterns so that developers may benefit from them without spending years learning them the hard way -- through experience alone.

Now, if Noodlez wants to figure out the design patterns and VB idioms for this particular problem, take weeks to do it, great, superb, it's a wonderful academic exercise.  If he were doing it for a customer, well that would be wasteful because he can find a better algorithm from a book (idiom-specific such as VB6 Black Book or generic algorithm books), or get a more experienced programmer.

From what I understand, Noodlez did a first-attempt port of a magazine article's C++ solution to a similar problem, so I'm not sure how much this dissertation of mine applies.  But if Noodlez respected the author of the article, he could be accepting the solution as a DESIGN PATTERN, and thus an acceptable solution in possibly any language form.

Hope this helps.

[Camel]

There's nothing wrong with trying to do the best possible job with design patterns, and a particular tool's idioms.

In the book "The Practice of Programming", author Brian Kernighan proposes that programming languages have "idioms" -- conventions that experienced developers use to build common coding elements.  These are similar to design patterns, but are finer in granularity.  Idioms are more generic than design patterns.  They have more to do with the language than with solving a particular type of problem.

In the book "Design Patterns", author Erich Gamma propose that there are certain patterns in software design that expert developers regularly use and recognize in code written by others.  The book seeks to formally catalog these patterns so that developers may benefit from them without spending years learning them the hard way -- through experience alone.

Now, if Noodlez wants to figure out the design patterns and VB idioms for this particular problem, take weeks to do it, great, superb, it's a wonderful academic exercise.  If he were doing it for a customer, well that would be wasteful because he can find a better algorithm from a book (idiom-specific such as VB6 Black Book or generic algorithm books), or get a more experienced programmer.

From what I understand, Noodlez did a first-attempt port of a magazine article's C++ solution to a similar problem, so I'm not sure how much this dissertation of mine applies.  But if Noodlez respected the author of the article, he could be accepting the solution as a DESIGN PATTERN, and thus an acceptable solution in possibly any language form.

Hope this helps.

Agreed all-around, but there comes a point in every vb guru's life when he becomes constrained by the limits of the language. Typically, the programmer goes through denial -- refusing to accept that his code runs slowly because the language sucks. Said programmer may try to tweak his code to optimum efficiency. While the programmer may make his code hundreds -- even thousands -- of times more efficient, he has failed to realize that the size of the vb overhead dwarfs even what he origionally started with, making all of his efforts for a relative nothing.

Sorry for the drama, but here's my point: VB can teach concepts, but it's never going to be efficient. I can't imagine any serious client wanting a fast and small program in vb that requires that much work when it could be done much simpler and quicker in a higher level language such as C.

[Grok]

According to your profile you are 16 years old, thus I can understand how you currently possess the ultimate wisdom on what corporations want, need, will demand, will pay for, and of course the justifications for it all.

Being that you have reached eternal grokness, there is no room for you to learn more.



That is, at least, until you get a little older and wiser