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.
