disadvantages of using STL

[Pallav singh]

Q What are the disadvantages of using STL ?

Thanks in advance
Pallav Singh

 

[Pallav singh]

The main disadvantage is that you need to learn those at least somewhat
before you can use them.  All the other disadvantages pale in comparison.

V

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MFC CMap (works much faster than STL map because STL implementation
is
tree-based while MFC one is hash-based).

Pallav

 

[Alf P. Steinbach]

* Victor Bazarov:

Uh... MFC CMap, what?

It seems Pallav Singth thinks a that a similarity of names means roughly
equivalent functionality.

If it's true that MFC CMap is hash-based, then that is a hash table, presumably
without simple O(n) traversal of elements, and certainly not in sorted order,
but on the other hand offering O(1) insertion and look-up -- a different
trade-off from the one in std::map, and used for different purposes.

C++98 doesn't have a container based on hashing, but TR1 has, Boost has, and
C++0x will have.


Cheers,

- Alf

 

[James Kanze]

Q What are the disadvantages of using STL ?

Compared to what?

 

[James Kanze]

* Victor Bazarov:

It seems Pallav Singth thinks a that a similarity of names
means roughly equivalent functionality.

If it's true that MFC CMap is hash-based, then that is a hash
table, presumably without simple O(n) traversal of elements,
and certainly not in sorted order, but on the other hand
offering O(1) insertion and look-up -- a different trade-off
from the one in std::map, and used for different purposes.

Note that hash tables are only O(1) if you have a perfect
hashing function. They can be close with a very good hashing
function, but approch O(n) with a very bad one. Writing a good
hashing function isn't trivial.

The result is that std::map is sufficiently fast most of the
time, and much easier to use, unless you've actually done some
research on hashing, and have all of the necessary tools in your
tool kit.

 

[James Kanze]

Relative to what? The STL is imperfect, but I don't think
I've seen a better library of algorithms and containers.

Better in what way? In some ways, the STL ranks as one of the
poorer libraries I've seen. On the other hand, it's standard,
and so it is there (and every competent C++ programmer knows it,
more or less, so that's one thing less they need to learn to
read my code). And whatever its defects, it's more than
sufficient for most uses, so there's no reason to choose
something more exotic.

 

[coal]

There's a nice table comparing intrusive and non-intrusive containers
in these
pages: http://www.boost.org/doc/libs/1_38_0/doc/html/intrusive/.


Table 10.1. Summary of intrusive containers advantages and
disadvantages


Issue Intrusive Non-intrusive --
STL
------------------------------------------------------------------------------------
Memory management External Internal through
allocator

Insertion/Erasure time Faster Slower

Memory locality Better Worse

Can hold non-copyable and Yes No
non-movable objects by value

Exception guarantees Better Worse

Computation of iterator from value Constant Non-constant

Insertion/erasure predictability High Low

Memory use Minimal More than
minimal

Insert objects by value retaining Yes No (slicing)
polymorphic behavior

User must modify the definition of Yes No
the values to insert.

Containers are copyable No Yes

Inserted object's lifetime User (more complex) Container
(less complex)
managed by

Container invariants can be Easier Harder (only with
containers of pointers)
broken without using the container

Thread-safety analysis Harder Easier


There's also a performance comparison between Intrusive and Non-
intrusive
containers in those pages.

And yes, G-d willing, support for some of the Boost Intrusive
containers
on webEbenezer.net will come on line before the end of this month.

MFC CMap (works much faster than STL map because STL implementation
is
tree-based while MFC one is hash-based).

http://www.boost.org/doc/libs/1_38_0/doc/html/unordered.html

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Juha Nieminen]

What is this, a Zen koan? Every question met with a question? Better
in the sense that it's faster, more generic, and easier to use. When I
used the word, I was thinking of the old, intrusive containers used with
MFC, and of the Java collections framework.

How do you use intrusive containers with pre-existing types (which
don't know anything about the containers in question) and basic types
(ints, doubles...)?

 

[Bart van Ingen Schenau]

Q What are the disadvantages of using STL ?

Thanks in advance
Pallav Singh

Compared to rolling your own, the disadvantages are that you don't
learn as much about implementing containers and algorithms.
Another disadvantage is that you don't have to spend so much time
hunting bugs.

Bart v Ingen Schenau

 

[James Kanze]

What is this, a Zen koan?

Socratic reasoning.

Every question met with a question? Better in the sense that
it's faster, more generic, and easier to use.

Faster and easier to use? It ranks close to last among the
libraries I've used in that respect. More generic, perhaps,
although not always. On the other hand, it's far more complete
than any other library I've used, and it's generally more
orthogonal than most.

Most importantly, of course, it's standard. So you don't
(usually) have to think about it.

When I used the word, I was thinking of the old, intrusive
containers used with MFC, and of the Java collections
framework.

I've never used MFC, but I find the Java collections easier to
use than the STL (although they also have some problems);
they're also more generic, at least in some ways. (Arguably,
the earliest versions were too generic. You could put a Toto
into a collection, and try to get a Titi out, only getting an
error at runtime. From what I understand, this defect has been
fixed, but I've not had the occasion to use Java since then.)

 

[James Kanze]

I thought it was "compared to *not* using it"... <g> I mean,
what is the alternative of "using"?

Yes, but... Not using it how? If the alternative being
considered is not using any containers, or any algorithms... if
you can easily do that, then the STL is just so much extra
baggage (as is any other container library you can think of).
If the alternative being considered is to implementing your own
libraries, the STL has distinct disadvantages when it comes to
job security (if you role your own, it will take a lot longer to
implement the application, and if you do it cleverly enough,
you'll be the only person who can maintain the code), but I
can't think of any others. If you're comparing it to the Java
collections, of course, the STL has some very distinct
disadvantages if you're programming in Java (it doesn't work in
Java), but just the reverse is true (for the same reason) if
you're programming in C++. If you're comparing it to OSE, it's
not as cleanly designed or as easy to use, but it's more
complete, and above all, it's standard, so new programmers on
the project can be expected to already be familiar with it.

And so on. Depending on the alternative you are considering,
the disadvantages will vary. In all be exceptional cases,
however, they won't be enough to outweigh the advantage of it
being standard.

 

[Noah Roberts]

Q What are the disadvantages of using STL ?

Efficiency.

 

[Noah Roberts]

Compared to rolling your own, the disadvantages are that you don't
learn as much about implementing containers and algorithms.
Another disadvantage is that you don't have to spend so much time
hunting bugs.

Which reminds me of another disadvantage:

You don't get to spend all your time dealing with some hacked up version
of an intrusive linked list.

You don't get to write your own linked list for each type you want to
store in a linked list.

And...you don't get to add linked list management functionality to every
type that needs to be a node in a linked list.

With all these problems in mind, I don't know why anyone would even
consider using STL in a production product.

 

[osmium]

Q What are the disadvantages of using STL ?

It encourages others to use the STL, furthering it's lifetime and even more
widespread use. The STL is WAY over thought and as a result unduly
complicated. When you need an 800 page book (Jossutis) to describe how to
use a library offering these services, you have clearly lost touch with
reality. It looks to me like the work of a group, a BIG group, of academics
has been grafted onto the work of a lone practicing programmer who defined
C. The end result is a nasty slurry.

 

[Gert-Jan de Vos]

It encourages others to use the STL, furthering it's lifetime and even more
widespread use.  The STL is WAY over thought and as a result unduly
complicated.  When you need an 800 page book (Jossutis) to describe how to
use a library offering these services, you have clearly lost touch with
reality.  It looks to me like the work of a group, a BIG group, of academics
has been grafted onto the work of a lone practicing programmer who defined
C.  The end result is a nasty slurry.

Nonsense. Jossutis describes the STL and the other parts of the
standard library.
Generic Programming and the STL by Matt Austern is a very good book on
the STL. It
describes the STL in some 70 pages. Then the original paper that
described the
full STL was much smaller still. STL uses only 4 concepts and only 3
that you need
to understand to use it effectively. The STL was the work of one man,
an academic?
Yes, a mathematician! I guess that's why it can do so much with so few
basic concepts.

 

[Alf P. Steinbach]

* Gert-Jan de Vos:

Nonsense. Jossutis describes the STL and the other parts of the
standard library.
Generic Programming and the STL by Matt Austern is a very good book on
the STL. It
describes the STL in some 70 pages. Then the original paper that
described the
full STL was much smaller still. STL uses only 4 concepts and only 3
that you need
to understand to use it effectively. The STL was the work of one man,
an academic?
Yes, a mathematician! I guess that's why it can do so much with so few
basic concepts.

Well, there are three quality levels of headers in the standard library:

Medimum to very good: original STL headers (Stepanov's work (note:
Stepanov isn't acknowledged in the standard)).

So-so: language support (e.g. <memory>).

Really bad, avoid: all the i/o stuff, plus <string> (note: some of
responsible here are acknowledged in standard).

The really bad headers are the result of groups of academics and others trying
in committee fashion, and/or with academic view, to improve existing work.

Bjarne's original iostreams were practical, and I think they were excellent
design & idea for the time (early 1980's); the later "improvements", plus
transferring original idea to contexts it didn't apply to, it's all beeen
downhill very fast, quality-wise, so that now it stinks (hold your nose!).


Cheers,

- Alf (evaluator mode)


PS: The "avoid" above is an ideal that can't be achieved: we just have to use
std::string / std::wstring as string data carriers, there's no other option.

 

[Juha Nieminen]

Well, I don't use them. When I had to use them, I wrapped them in
classes that implemented the relevant interfaces.

So you basically replicated the STL functionality?

 

[Juha Nieminen]

When you need an 800 page book (Jossutis) to describe how to
use a library offering these services, you have clearly lost touch with
reality.

I don't believe the 800 pages are dedicated to the basic usage of the
STL. You certainly don't need that much text for basic and even advanced
usage of the STL.

Just because a book might go very deep into what you *can* achieve
with the STL, that doesn't mean you *must* read the entire book in order
to efficiently use the STL. For example, how many times have you used a
custom allocator with an STL container? How well can you use the STL
without even knowing what an allocator is? Just because a book might
explain custom allocators in detail doesn't mean you must read that
chapter in order to use the STL.

 

[Juha Nieminen]

Herein lies another disadvantage: you have to sift through an 800 page
book to figure out the simple stuff and realise you don't need to read
all of it to make use of the STL... Bummer!

If that's the case, then the book is really badly written. Buy a
better one.

 

[Juha Nieminen]

Huh? No, sorry, I mean that I wrapped the elements, not the containers.
The STL doesn't require you to wrap anything, or derive from any
interface; it just requires you to support standard syntax. In
contrast, some of the older collection libraries, include MFC (IIRC),
required that any element to be stored in (say) an "array" collection
had to derive from an "array element" abstract class, and override
various member functions. I prefer the STL approach.

What I meant was that by encapsulating the existing types into classes
that implemented the relevant interfaces, you are basically exactly
replicating the way which STL containers use to manage these same elements.