This is the mail archive of the gcc@gcc.gnu.org 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


Converting to C++ is a major change. Does that justify to have a major release (5.0.0)? 

Bingfeng

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
> Richard Guenther
> Sent: 02 June 2010 10:36
> To: Gabriel Dos Reis
> Cc: DJ Delorie; Hargett, Matt; gcc@gcc.gnu.org
> Subject: Re: Using C++ in GCC is OK
> 
> 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?
> 
> 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.
> 
> Richard.
> 
> >> 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]