Converting to C++ is a major change. Does that justify to have a major release (5.0.0)?
Bingfeng > -----Original Message----- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@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 > <g...@integrable-solutions.net> wrote: > > On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie <d...@redhat.com> wrote: > >> > >> "Hargett, Matt" <matt.harg...@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.
