The STL has one absolute advantage: it is standard. Anyone
coming into your project from elsewhere should be more or less
familiar with the interface to std::vector, etc. Where as he
will first have to learn your in house classes. The STL may not
be an example of good design, but it's good enough, and it's
standard, and that means that it should be used by default.
The design of the STL is pretty good for what it is
intended for. That is, it is intended to be a fairly
general use thing, reasonably efficient for many
tasks. If you have a very special task it is *possible*
that you may need to "roll your own" to obtain some
specific improvement. Say, something related to some
particular hardware or some such. However, it is
quite likely that it would take a huge amount of
effort, and require a much better than average coder,
to get a better design than the STL. A lot of really
smart people worked pretty hard on it.
It's worth expanding on the advantages of a standard.
The existing STL containers and algorithms are already
extensively documented. This means that a project that
makes use of them does not have to create docs for that
part of the code. If you "roll your own" you will have
to not only do all the design and development effort,
but you will have to write documentation for it, test
suites, regression testing, test reports, etc. For
projects where QA is a big deal, this could be a big
amount of work saved.
A reasonably good STL implementation will be unlikely
to have any bugs. So, when you test your code you will
be confident that any problems are not in the STL parts.
With a "roll your own" you are going to be tempted to
go on a bug hunt through the container code.
If you do find a bug in the container code, it may have
a cascade effect through the entire project. Usually
the cost of fixing any given bug will increase quite
rapidly over time, particularly when that code is
used by other code over large parts of the project.
Thus having a standard library for widely used
things like <vector> is a Very Good Thing.
If you do find a bug in one implementation of the STL,
it is possible to get another implementation, often
from a completely different vendor. The interface
is the same and so you should simply be able to
re-compile with the new implementation and continue
on as before.
There is a very wide community of people who have
extensively used the STL. Thus you can ask questions
about proper use, efficient use, problems understanding,
compiler issues, etc., and have a large number of
people who may know the answer. With a "roll your
own" the number of users is probably much smaller.
A problem could delay you till you solve it yourself.
If you work on an STL project, your experience will
count when people are hiring for other STL projects.
Your experience on a "roll your own" probably won't.
This will quite likely mean you get a higher rate
on the next project. Or can pick and choose what
projects you want instead of taking whatever you
can get.
Socks
