So following up my recent forums post regarding Expanding Swift Overlay and understanding it's practicality I suppose I have an idea for which I can make a good proposal.
Here's what I think can be a potential way of expanding the overlay, so as @egor.zhdan explained,
std::string and it's use case from this snippet, I think we can extend this to the following
STL containers which are quite useful, (some of them might have already been implemented):
std::priority_queue-> Quite useful container due to it's heap-based implementation.
std::deque-> Allows quick
back()operations when needed.
std::list-> Doubly Linked list based structure (more info below).
std::map-> Guaranteed quick access time (~log(n))
std::multiset-> Similar to set, allowing duplicate elements.
(there might be some more useful ones which I may have missed out.)
The above containers are widely used, and quite useful in many ways, each of them have their own internal implementations of doubling linked list, pointers, hash tables, heaps, etc. Although 'expanding the overlay' is the primary goal of the project, I do have some ideas which I suppose would we quite beneficial, for example, most of them are quite common to use, often
std::list can be quite useful to quickly insert, delete and modify elements in a certain array type (or equivalent Swift type), we can potentially also add a new functionality specifically to this type of container, regarding
access of elements, as that's the only downside of
std::list, which can be fixed by using a map of this kind
std::unordered_map<std::iterator, <type>>, in that way, if the developer (or user) knows the
STL iterator, we can get constant access time (O(1)).
Also particularly regarding the last 2 containers (i.e. unordered_*), I have a nice idea of improving the existing hash table issues and collisions in C++ as there are definitely cases where there's a significant slow down and could lead to long waiting times making the developer think it might be due to some other problems, while the typical
std::map has it's implementation based on Red-Black trees delivering O(log(N)) time complexity, often languages do offer a quick access time and low storage hash tables. So while 'expanding the overlay' in Swift, we can make some changes or even offer a way for the user to use a custom hash table of their own.
We can also add
std::tuple, for supporting multiple element types, compared to
std::pair, making it more flexible to use in Swift.
I think this gives a brief idea of my thoughts and understanding of adding features and improving the overlay!
Request your view point, changes and recommendations @egor.zhdan!