On Wed, Jun 2, 2010 at 4:35 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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?
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.
