On Wed, Jun 2, 2010 at 8:38 AM, DJ Delorie <d...@redhat.com> wrote: > > "Hargett, Matt" <matt.harg...@bluecoat.com> writes: >>> As noted earlier I think we do want to use some STL classes. >> >> I agree with Mark's earlier declaration that it is relatively >> straight-forward, low-hanging fruit to replace VEC_* > > I do not object to simple and obvious uses of STL to replace equivalent > functionality, but I've seen code that layers STL over STL over STL to > the point where the code is very difficult to understand. Hence, my > recommendation to avoid STL *at first*. It teaches caution against > over-abstracting and arbitrary complexity. >
STL is good, but may surplus what GCC really needs, and will introduce many complex, "uncontrollable" C++ features. Personally, I think what GCC need most is an simple, generic, one layer containers of pointers to objects, with their iterators. Instead of containers of arbitrary types. That means the type parameters of the standard templates is restricted to pointer to objects. If you can't refrain from using STL and don't like the mess it may introduce, you can derive classes from instantiated standard templates with pointer as type parameters, and use the derived, template-free classes in rest of your code. And, I will be glad to see C++ strings replace all uses of C strings, but this may be hard. I don't think TREE and RTL access macros like TREE_CODE, TREE_TYPE, TREE_OPERAND, GET_CODE, GET_MODE, XEXP, etc should be replaced by virtual methods. But I think dump and debug codes may be implemented as virtual methods. -- 徐持恒(Chiheng Xu) Wuhan,China
