This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 4:35 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Tue, Jun 1, 2010 at 7:38 PM, 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*.
>>
>> 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.