Well, on the one hand I agree - but on the other hand I see people
eagerly waiting to be the first to post patches to convert all
VEC uses that allocate from the heap(!) (yes - we can't use STL
for GC allocated stuff!), leaving us with files that use a mix of
stl::vector and VEC. VEC is clearly superior here in that it provides
a general vector implementation which can allocate from GC space,
heap or even the stack. Why switch to a less capable implementation?
OTOH for pointer-map and pointer-set I see little value keeping it
(it can't be used for GC allocated stuff), so std::map and std::set
are a perfect fit.
Seriously? Hashtable vs. red-black tree looks like a major change.
Remember that pointer-sets in the beginning were introduced because they
were faster than libiberty hashtables.
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01227.html
For libiberty hashtables the same issues exist as with VEC - furthermore
there is no real hashtable implementation in C++98, so there
isn't even a 1:1 thing to substitute.
Right. But importing libstdc++'s hash_set/hash_map and use that instead
would probably give a decent speedup, so why not do that?
Personally, the only sensible change that I see is to change our
macro-based pseudo iterators to be "real" STL iterators, and using STL
algorithms such as sort when applicable. This BTW means that iterator
operator== and operator++ would be a special case in which operator
overloading would be allowed.
Similarly, we could still use gengtype's VEC machinery but with a
template-based implementation instead of doing everything in macros; and
with a C++ "usage flavor". Interestingly, this would push C++ usage in
exactly the opposite direction: the only feature we'd use (though in a
controlled manner) would be templates.
I know Ian doesn't like custom containers, and I agree, but our GC
requirements make things a bit clumsy.
Paolo
