A bug with popping structures containing string fields has been fixed.
Download link is in the first post.
A useful but boring post.
We expect better from you. At least a few unsubstantiated innuendos and malicious accusations are required.
Well funny you should say that, because I did hear a rumour regarding that fellow Dare2 and his strange absence from these forums. Apparently, as the word on the street would have it, he got romantically involved with a dolphin and a tin of sardines and was caught by a Russian trawler just off the coast of Finland wearing just a pair of slippers and a false moustache. He was eventually sold to a Greek circus owner on a no win no fee basis and now spends the majority of his time balancing on one leg whilst waiting for his other leg to open a small business in the south of France...
The guy's a flipping dreamer!
I may look like a mule, but I'm not a complete ass.
Push obviously adds the value
Pop returns and removes the value
Peek is a function similar to Pop where you can retreive the information of like Pop, but it *isn't* removed from the stack. Very useful if you want to check certain values before letting it through the Pop.
Of course, Peek can work currently by calling Pop and then Pushing it back on the stack. But that's a lot of work when you can just return what is currently on the stack without actually removing and adding it again.
Well, no offence, but I do know what a Peek operation is, I just don't see how it's important for a stack - certainly I've never seen such a function added to a stack utility before!
The truth is that I certainly have no need for such a function and so I will not be adding it. However, beings as the utility is in source code form, please feel free to modify it in any way you wish.
I may look like a mule, but I'm not a complete ass.
Perhaps my oop class for dynamic arrays will help which is a few posts down in this forum section. You could easily adapt this to give the functionality of a stack and because it is based upon an array, you immediately have the equivalent to a Peek() function.
The two classes share a common code base anyhow.
I may look like a mule, but I'm not a complete ass.
Hey srod, are these stacks dynamic? Can I create them with 10 elements then push 12 and have it resize if there is not enough space?
Edit: Don't feel you need to add it if it doesn't, as I probably won't be doing anything other than testing with it now. Wouldn't want to you go to any trouble adding a feature that doesn't get used :)
Edit: never mind, tried it and it didn't work.
If you paint your butt blue and glue the hole shut you just themed your ass but lost the functionality.
(WinXPhSP3 PB5.20b14)
you can use the ResizeStack() method to resize the stack. Combine this with the SizeOfStack() method and you can easily either implement dynamic growth yourself or easily adapt the code so that the stack does indeed grow dynamically as you push more elements etc.
Either way should, as I say, be quite straight forward.
I may look like a mule, but I'm not a complete ass.
srod wrote:Well, no offence, but I do know what a Peek operation is, I just don't see how it's important for a stack - certainly I've never seen such a function added to a stack utility before!
I've always had the impression that it is a widely known and used stack-function. It's really useful, and essential for example in making a stack-based shunting yard algorithm (more here). Needed it myself the other day while I was building an expression evaluator -- I would've used your stack code but decided to code my own since yours didn't have the functionality I needed.
But I'll be sure to use your code later, it really seems easy and powerful. So thanks!
I know Dijkstra's algorithm for converting infix expressions to reverse Polish very well and nowhere does the algorithm specify a need to peek at values below the top of the stack. Indeed, I have a utility in these forums somewhere for evaluating expressions based upon this algorithm, and whilst it is heavily reliant upon a stack, it most certainly does nothing but push and pop! Indeed, it would cease to be a stack in my opinion if the data structure in question is being used in other ways! In fact you'd perhaps be better off with an array if you do need to peek around at elements lying below the top of the stack etc.
Still, I'm not questionning your reasons for needing to peek and poke around the elements of a stack etc. I'm just trying to find an excuse not to add it to my code as I didna have the time at the moment! It would be an easy addition however.
I may look like a mule, but I'm not a complete ass.
srod wrote:I know Dijkstra's algorithm for converting infix expressions to reverse Polish very well and nowhere does the algorithm specify a need to peek at values below the top of the stack. Indeed, I have a utility in these forums somewhere for evaluating expressions based upon this algorithm, and whilst it is heavily reliant upon a stack, it most certainly does nothing but push and pop! Indeed, it would cease to be a stack in my opinion if the data structure in question is being used in other ways! In fact you'd perhaps be better off with an array if you do need to peek around at elements lying below the top of the stack etc.
Still, I'm not questionning your reasons for needing to peek and poke around the elements of a stack etc. I'm just trying to find an excuse not to add it to my code as I didna have the time at the moment! It would be an easy addition however.
No no, maybe I wasn't being clear. I didn't mean that I'd need to peek (or poke for that matter!) at values *below* the top of the stack, only to return the value of the element that lies at the top of the stack, without popping it. That's normal stack functionality to me at least, but I could be wrong.
