Re: disadvantages of using STL
Hi Tony,
On 24 Mrz., 11:23, "Tony" <t...@my.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
One man's advantage is another man's disadvantage. If you're
trying to hang on to a job, the fact that not using the STL
reduces efficiency, so that it takes you a year to finish the
job, rather than six months, could be considered an advantage
(provided you're sure that the employer doesn't realize that
you're artificially creating extra work, and fire you for it).
And if you're selling hardware, the fact that the software runs
slower, and that the customer needs two machines instead of one,
is also an advantage.
I was just alluding to the fact that the template-based STL is going to b=
e
more efficient than any non-template or "partially templatized" version i=
n
regards to program PERFORMANCE. But now that we're talking about it, in m=
ost
....for some design you refer to by "non-template" and "partially
templatized". It would be nice if you can give some examples or point
to some other resource that explains these designs. Otherwise it's
hardly possible to list pros and cons. What kind of container are we
talking about? Linked lists?
I would say I'm fairly familiar with the principles behind the STL
containers and boost::intrusive. I'm not arguing against
boost::intrusive. But those intrusive containers are hardly
universally applicable -- try intrusive::list<int> ;) -- and only
useful in some special corner cases where it really matters, IMHO.
I'm still interested in what your "void*" design looks like, how it
achieves its type-safety w.r.t. the interface and why it should be
better than any of std::vector, std::list, boost::intrusive::list in
some specific case. There's also the boost pointer container library
but I think it might become obsolete once we get to store objects of
type unique_ptr<T> in standard containers.
cases, it probably doesn't matter. I could "phone home" for calculations =
and
still have an adequate app program in some scenarios. Not in the Runge-Ku=
tta
physics stuff, but scientific calculation is hardly the norm.
Why exclude it if you can be good at this, too? (i.e. using
std::vector<double> as a member of a matrix object for managing all
the elements, etc) You must have some compelling reason to do so. Is
it easier to learn than the STL?
In this sense, the biggest disadvantage of the STL is that
everyone understands it, at least the basics. So it's harder to
write code that no one but you understands, so as to lock
yourself into a job.
I'm not going to even try to grok that, because I don't think it is an
issue.
Please read again the very first quoted paragrah in this post.
One of the main STL advantages is that it's part of the C++ standard
(as previously mentioned by James Kanze). Another point for STL
containers would be that they're rather universal in comparison to
other approaches. Sure, in some special cases intrusive::list<T> may
be what you want for some T that derives from list_hook<>. But it's
practially the as std::list<T*> except for some performance and
exception-safety issues.
Cheers!
SG