Re: [Algorithms] fundamentally better containers

[Eric Y. <er...@od...>]

Speaking about pragmatic issues. I think if we are talking about new
containers, we would want to fix some of the subtle gotcha's in STL:

1) In map's, there is an overloaded [] operator. This not only indexes into the
map, but if the key doesn't exist in the map, it make a new node on the spot.
I've seen code like: "if (animation[key] == NULL) ..." which is true if the key
doesn't exist but it also adds a bogus entry in the map! I know why they do
this, it's so you can do " map[key] = new element ". I think [] should be used
for 'finding' only and not adding.

2) Iterators all have an "erase()" member, however whether the iterator is
valid after that operation or not is different for different containers. In
maps, (with our STL) the iterator is no longer valid, and no iterator is
returned. In a vector or list, you are not sure if 'erase' will leave the
iterator on the next element or the element after it. In these cases, you are
returned an iterator that IS valid. etc. The fact that the interface is
consistent would lead you to believe that the results of "erase()" would be
consistent, but they are not. I don't buy the 'well what do you expect, they
are different implementations' argument. When somebody calls 'erase', the
iterator should always point at the 'next' element. If that means returning an
iterator, so be it, but that should be consistent across all 'erase' calls.

3) There are a variety of ways in which STL is constructed that interfere with
debugging. They have fairly deep hierarchies, which means that you end up
"stepping-in" to layer after layer of hierarchy before you get to the relevant
code. The data entries (e.g. in maps) often don't acquire the type information,
so you can't look at the data conveniently in the debugger. etc.

Solutions to these shouldn't hurt performance, but they would prevent many
subtle bugs...

- Eric



chr...@pl... wrote:

> Nik Hemmings wrote:
> >> Considering that we, AFAIK, don't have a single growable array in our
> >> engine, I'm sort of curious to hear where all the people discussing
> >> them find a need for them?
> >
> >Tools, perhaps?  Conversion tools can become prohibitively expensive to
> run
> >unless you spend a reasonable amount of time optimising them.  They often
> >need dynamically resizeable containers.
>
> In theory, certainly. I was however, perhaps not as clearly as I intended,
> asking for *actual* (and justified) uses of them. I.e. not hypothetical
> uses.
>
> I don't intend this as a flame-bait (so please don't take it as such), but
> it seems to me that often people are tempted into a sort of mental
> masturbation
> where it's more important to use a fancy (overengineered) solution, because
> "it is right" where the pragmatic answer would be something much more low-
> brow and not nearly as 'right' or software-engineeringly correct.
>
> So, anyway, seeming that we don't use them (and overall avoid dynamic
> allocation within engine/game as much as possible) I was just honestly
> curious where people actually use growable arrays. Especially in a
> game/engine context, rather than in the tools.
>
> Christer Ericson
> Sony Computer Entertainment, Santa Monica
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list