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

On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis
<> wrote:
> On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie <> wrote:
>> "Hargett, Matt" <> 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*.
> I think that would be most unproductive and misguided.
> The first thing we should do is
> ? ?(1) resist NIH
> Then
> ? ?(2) we should prefer standard solution over home-grown hacks, unless
> ? ? ? ? there is a clear demonstration of value. ?For example, it would be
> ? ? ? ? unwise to prefer our current VEC_xxx over std::vector. ?Conversely,
> ? ? ? ? we should probably have our own hash table, since there is none in
> ? ? ? ? C++98.

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.

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.


>> It teaches caution against ?over-abstracting and arbitrary complexity.
> avoiding over-abstracting is not reached by banning standard solutions -- that
> only lead to more brittle and bug-ridden hacks.
> The way we avoid over-abstracting is to have people write simple codes, and
> reviewers use their best judgments.

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