This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using C++ in GCC is OK

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]