Using C++ in GCC is OK

[Paolo Bonzini]

> 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