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. > 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.