ID:42717
 
upContainers by Unknown Person
A library that implements basic data structures used in everyday programming.
4 fans · Created May 9 2008
upContainers is a library that defines and implements primitive data structures used in everyday programming. Currently, the library defines stacks (/Stack), queues (/Queue), and sets (/Sets), and is easily implementable in your project. Documentation is located in the library.

upContainers
HOLY DUNG I NEEDED TO KNOW THIS STUFF!!!
Oh darn! I was going to make a library with those data structures, but looks like I'm too late :/. It looks pretty cool btw.
The one thing that bugs me in this library is that stacks and queues use lists instead of datums. While the maximum amount of lists that can be used in a program is relatively small and should be used with care, there can be a few billion datums active at a time.

How about going along the lines of how stacks are programmed here?
That particular linked list method has its ups and downs. The library will eventually support a separate linked list object which can also be used as a stack or queue.
That sounds good, then. But I still think that you should use datums instead of lists.
First of all, nice job in adding functionality to DM. I'm a long time developer (1977) but just started to play with DM this past week. Looked thru your code, made a couple minor fixes, and enhancements. Hopefully they will prove useful to some.

Enhancements:
Stacks and Queues can be initialized with singular data instead of lists. This saves you from creating an unnecessary list just to provide a single item for initializing your Stack or Queue.


Fixes:
In Stacks and Queues, when not providing any initial data and attempting to read from the Stack or Queue (with getTop(), getFront(), and getBack() ) you will receive errors due to the list not existing and attempting to access contents via an index.


Replacement code:
http://www.tpblocks.com/tmp/codechanges.html

Testing Code:
http://www.tpblocks.com/tmp/testcode.html
Hi Thurnok, thanks for the input. Oddly enough, I had one of the fixes already done before you posted, but you helped point out the other function the error was also in.

Stacks and Queues can be initialized with singular data instead of lists. This saves you from creating an unnecessary list just to provide a single item for initializing your Stack or Queue.

I'm debating whether this kind of feature is useful. If someone would want to initialize a stack or a queue with only one value, it would just be as effective to call Push() or Enqueue() right after initializing it. I can't see many reasons why a programmer would want to initialize a stack or queue with one value, but if you can give me a good enough reason to add that kind of functionality, I will consider it. Ideally, I'd like to keep these data structures as bloat-free as possible, and to only add essential features.
Stacks and Queues can be initialized with singular data instead of lists.

I'm debating whether this kind of feature is useful.

Ideally it should support both. And there's no reason why it can't.
Well, the couple of reasons I can think of off the top of my head would be:

- Code elegance for the person using the library.
- processor cycles used

For example, when using the output of some other function (assuming it doesn't output a list):
var/Stack/S = new(<somefunc>)

as opposed to:
var/list/L
L = new()
L += <somefunc>
var/Stack/S = new(L)

or:
var/Stack/S = new()
S.Push(<somefunc>)

The first alternative is obviously not as elegant plus extra overhead, the second makes two calls to the obj vice a single call. I'm not that familiar with DM yet, but in terms of C++, an IF() conditional does not take as many cpu cycles as an additional call to an object's interface function.

Also, the particular interface functions in reference execute the same statements as well as some additional ones not actually needed when creating an initial list (assuming not setting max=0). In terms of cpu cycles for initializing a Stack or Queue with a single item, I believe the code modifications I pointed out would be more effecient. This does however, have the caveat of breaking the maxlen for cases of max=0, but since there are no functions for changing the maxlen, I would think it more beneficial to prevent the occurance since I cannot imagine why one would create a Stack or Queue with a maxlen=0 unless function(s) were added for modifying a Stack/Queue length.

That being said, one would have to do some usability testing to determine if the single additional IF() statement used over the course of an entire session of an application averaged in more cpu cycles than without based on whether the app more commonly created a Stack or Queue object passing no arguments, a list as an argument, or a single value as an argument.

Either way, good stuff to have. Seems like DM would have had functions for these built-in. Perhaps a future update will, but in the mean time, nice to have this library handy.