Using C++ in GCC is OK

[徐持恒]

On Wed, Jun 2, 2010 at 8:38 AM, DJ Delorie <dj@redhat.com> wrote:
>
> "Hargett, Matt" <matt.hargett@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