As I've mentioned before, BYOND does not use the standard template libraries. This is for a few reasons, the biggest being that BYOND basically predates them. At one point I tried using them, but Tom was concerned, rightly, that adding another library into the code was a major complicating factor, and also at that time redesigning other stuff to use STL simply wasn't worth it; so that idea was dropped. But another thing is, when performance matters I really want to know exactly what's going on, so I still prefer homegrown solutions.
The bottom line is, we never had a good string class until recently, and we never had other helpful items like hashtables and simple growable arrays.
As soon as I got back from vacation last weekend, I endeavored to write a good hashtable, using templates so it would be versatile. There are several uses under the hood I could think of for this, but a couple of really obvious ones stood out that will appear in the next release.
The first place I wanted to use a hash was to deal with the Tmovie class (text movies) for text mode. Again this isn't really used a lot anymore, but the overhead for "printing" the movies from their original text values, and having lots of copies of movies that are basically identical, seemed really bad. Wouldn't it be simpler to have a hashtable where I could look up whether a given string had been converted to a Tmovie already? So that's exactly what I did. All objects with text="o" will share the exact same Tmovie, which is refcounted, and when those appearances all go away then the Tmovie will be erased.
Another change was for color matrices. Ideally, I'd like all color matrices that have the exact same values to share the same memory. A hashtable is perfect for this, so I used one there too. Currently, only the client is making use of this feature, but there's a sort of precursor concept to shared buffers on the server that handles color matrices as well, so I'm looking to change the server to use this too. This means now that color matrices are also refcounted, and this in turn will make it easier for me to improve the MapIcon and MapIconSet structs I mentioned two posts ago.
There are other uses for hashtables to be found of course. They may have some relevance to regular expressions, for cases where users don't think to create the regex in advance and instead are always creating them on the fly, causing the parsing and tearing down to happen over and over. (I don't recommend that, but I'm sure people do it.) I'm currently using a variant of the Bag class to handle ban lists, which was originally intended to be done in STL, and it'd be nice to switch that over to hashtables that use DMString.
I've also been working on a template array class, especially one that can handle a growable array of DMString values, because there are some places under the hood where we need a list of strings, and having to free each individual string manually is kind of nuts. Chalk a lot of that up to BYOND's roots in pure C. Now to be sure we have growable arrays of other specific types, but I'd like to replace some of those as well where it's appropriate, to make the code cleaner.