Why do you need to 'iterate through' your vector? Vectors aren't linked lists(thats std list), so you shouldn't be having that problem.

That sounds better; if a vector is too slow, then you'd be having some serious problems.

Good luck!

Quote:Original post by Calin
... I can use the vector list like an array when reading the data and iterate through it when writing.

What exactly do you mean by that? std::vector is a random access container with random access iterators and is guaranteed to hold elements in memory contiguously. So read/writing/iterating is no different than doing it with an array, whether you where iterating using std::vector's iterator or using it's overloaded subscript operator makes no difference either.

If you want to improve preformance/efficiency of your widget toolkit don't use a linear sequence to hold all elements. Typical structure used for widget toolkits is the composite design pattern (think of it like a heterogeneous n-ary tree). With such a structure you have the ability to cull-out entire branches that are logically and/or spatially *grouped* together.

How are you identifying each GUI object? Is there some sort of unique identifier associated with each object? I ask this because you could use a hash_map, using the unique identifier as the key. That way, you don't need to iterate through the map, just do a find() and if the item with the id you pass in exists, it will return an iterator to it. It's much faster than iterating through a vector container.

I mentioned the hash_map because it's a very fast and efficient way of locating items with unique ids, which is what windows and controls are. When you create your control or window system using a hash_map, you can have a control manager handle the map of the controls.

Something like this:



Notice how the createControl function returns an unsigned int? That would be the unique id for the control that was just created. You could use a unique string as the unique id for the control; but, I find it better to use an unsigned int, as you have millions of possible ids that you could use. The static uLastId is to ensure that each new control being created will have its own id number, and there's no possibility of two or more controls having the same id. Neat, huh? I thought so.

If you take a look at how Ogre3D handles its mapping of objects, its create functions use a unique string as the identifier for the object, and the functions return a pointer to the newly created object. However, it's all based on preference and your design. I, personally, prefer to return the unique id as opposed to passing one in; but, the size of the variable being returned is the same, since an unsigned int and a pointer both take up 4 bytes.

Now, this probably isn't the most efficient way of doing it; but, it's definitely something that might spark an idea or two. :)

Hopefully I've made some sense, and I've actually gotten my code right. I'm still relatively new to hash_maps, so I might've forgotten a couple things. But, something you have to keep aware of is that if you used a std::vector, in order to find a particular control in that container, you have to iterate through the container and test against each control to see if that's the one you want, which could potentially take up a significant amount of time. Whereas, with a hash_map, you only need to call its find function and pass in the unique id you're looking for, and it will go directly there (assuming, of course, that the item you're looking for exists in the map).

It comes down to the order of magnitude for the container. A vector container has an O(n), whereas, the hash_map has an O(1), which is much faster. If you want speed for accessing your controls, I would highly recommend using a hash_map.