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.
