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 4:35 AM, Richard Guenther
<> wrote:
> 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?

std::vector takes an allocator parameter -- wihch can give storage from GC.

> 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.

std::set and std::map are  binary trees.
> 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.

yes, I did not propose to replace them with a C++98 standard container.

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