disadvantages of using STL

[Noah Roberts]

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

The Josuttis book is actually very well written. I've certainly seen
much worse. Each chapter starts with the basics and gets more complex
as you move forward.

What both Victor and the OP are forgetting is that this book is a
*Tutorial* and Reference. It is very difficult to write an effective
tutorial that addresses most learning styles in a matter of a few pages.
You need more than that, you need description, image, and example
along with exercises. The Josuttis book even leaves this latter part
out and is still a pretty effective instruction book (I'm a learn by
doing kind of person and I don't miss them too much).

It's actually pretty amazing that he's able to instruct that much and
well in just 800 pages something that's definitive reference (the
standard) is at least 200 pages. People complaining about 800 pages in
an instruction book on the C++ library are just lazy. It's a moderately
large library that's capable of doing quite a lot for its size.

The STL component of the standard library is actually the best thing
about it. That whole style of programming is quite effective and
represents some of the best in system design. The STL is well worth
studying as an example of great style and design.

 

[Noah Roberts]

Victor Bazarov wrote:
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.

The Josuttis book is actually very well written. [..]

What both Victor and the OP are forgetting [..]

Curious. Sarcasm detection apparently isn't working for some folks in
this thread... Oh well, time to ignore it.

Of course, it's not possible that your sarcasm expression system is buggy.

 

[Juha Nieminen]

I don't see how. The STL does not even require its elements to have
member functions, much less virtual member functions.

Oh, you mean the intrusive data containers are not template classes
but regular ones, and resort to use virtual functions on the members?

I thought intrusive data containers were supposed to be more efficient
than STL data containers.

 

[James Kanze]

They probably can be; the ones I've used just aren't.

I suspect that when you speak of "intrusive" containers, you
really mean non templated containers, where every member must
derive from some common base class (often Object). Generally
speaking, if you provide full value semantics, like the STL,
they will be less efficient. If you provide reference semantics
(as is usually the case), they will be as efficient as an STL
container of pointers, perhaps even slightly more so (although I
really doubt it).

In practice, this business of requiring everything to derive
from Object, and then having containers of Object*, is an idea
which has more or less been recognized as wrong. Jave started
this way, but has since added a limited form of templates to
avoid it. It fits in languages which don't do static type
checking, but that's not the case of C++ (nor Java)."

 

[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

As far as I can tell what is listed in this table is accurate,
but it seems like one thing is missing that in my opinion is
in favor of non-intrusive containers. There's no measurement
of access times of elements. For example, by dereferncing a
std::list<int> iterator you get right to the value you want.
But with an intrusive list you have something like:

struct MyClass : list_base_hook<>
{
int a_;
};

boost::intrusive::list<MyClass> intrsv_lst;

boost::intrusive::list<MyClass>::iterator it;

Now you have to go through the object first to get to
the int member. So while the table mentions that
insertion/erasure is faster with an intrusive
container, it doesn't say anything about access times.
I'm not really inclined to convert STL containers of
either a basic type or a pointer to a base type to
intrusive containers. The intrusive syntax is
clumsier and the accesses will be a little slower.
But if you have a container of user defined types it
makes more sense to me to use an intrusive container.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Lionel B]

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!

Yeah, especially as it lacks a contents page or index

( ;-) for the irony-challenged )

 

[Tony]

They probably can be; the ones I've used just aren't.

"I suspect that when you speak of "intrusive" containers, you
really mean non templated containers, where every member must
derive from some common base class (often Object). Generally
speaking, if you provide full value semantics, like the STL,
they will be less efficient. If you provide reference semantics
(as is usually the case), they will be as efficient as an STL
container of pointers, perhaps even slightly more so (although I
really doubt it).

In practice, this business of requiring everything to derive
from Object, and then having containers of Object*, is an idea
which has more or less been recognized as wrong. Jave started
this way, but has since added a limited form of templates to
avoid it. It fits in languages which don't do static type
checking, but that's not the case of C++ (nor Java)."

Another style of container implementation is via void*. No derivation from a
common base class needed. So you have at your disposal at least 3
implementation techniques: NIH style (derive from Object), STL templates
with value semantics, void* ptr based. I never liked the NIH style. My own
library used to be value based but is now void* based. I thought that
STL-style was the intrusive style because they make copies of the objects
that get put into them and then they own them (?). Also intrusive because
the actual objects get embedded into things like links directly via the
value semantic based template generation process. That sounds quite
intrusive (if not assuming).

Tony

 

[Tony]

"Faster and easier to use? [STL] 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."

That's least important IMO, especially if you mean it's ISO rather than
standard in general.

"So you don't (usually) have to think about it."

In what other way than with any other package of containers and algos,
commercial or house-specific that one is used to using?

Tony

 

[Tony]

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

I thought he meant vs. using an alternative: home-grown or commercially
bought or other.

Tony

 

[Tony]

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

You're assuming that because STL is complex and difficult to understand
immediately that all alternatives are so also. Probably also assuming that
nothing can be as reliable or perform as adequately as STL. All wrong
assumptions. And what good is a developer who can't implement say a linked
list? Moreso, what good is a development house or department that can't?
"Standard" an asset? Baah. That ISO put their seal on it is trivial and
quite possibly a negative aspect (overly-general comes to mind,
overly-complex comes to mind, semantically inelegant comes to mind...). The
right tool for the job is many more times than not, not "something ISO by
virtue of it's ISO-ness".

Tony

 

[Tony]

Efficiency.

He said DISadvantages.

 

[Tony]

The STL component of the standard library is actually the best thing about
it. That whole style of programming is quite effective and represents
some of the best in system design. The STL is well worth studying as an
example of great style and design.

Was STL the first to introduce the concept of algorithms working on
containers via iterators? If so, then your last statement, though a bit
strong, has some merit (there are other simpler ways that may be appropriate
for a given project and variations on the theme also). If it wasn't the
first to introduce that architecture, then I say the kudos belongs somewhere
else. The implementation, of course, is too obfuscated and complex to be of
"great style and design" even if the algo-iterator-container was first used
in STL (which I doubt, but I can't remember the early stuff anymore, say
Roque-Wave pre-template version, or Borland BIDS, e.g.).

Tony

 

[SG]

Hello Tony,


this is my understanding of what "intrusive" means:

Example: Intrusive smart pointers: You are required to add the
reference
counter to your object you want to manage.

Example: Intrusive Containers: You are required to derive from a base
class for your elements you want to manage.

In both cases you are forced to add some specific code to the class of
your objects. The pointer/container design is "intruding" your class.

Another style of container implementation is via void*. No derivation
from a common base class needed. So you have at your disposal at least
3 implementation techniques: NIH style (derive from Object), STL
templates with value semantics, void* ptr based. I never liked the NIH
style. My own library used to be value based but is now void* based.

IMHO, that was a bad decision. The generic/value semantics approach
is
the most universal one because you can choose to manage (smart)
pointers
OR your objects directly. Also you lost type safety by using void*.

I thought that STL-style was the intrusive style because they make
copies of the objects that get put into them and then they own them
(?).

There's nothing wrong nor intrusive (by the definition I use) with it.
If you don't want copies (because copying is expensive or not
appropriate) and/or runtime polymorphism you could use (smart)
pointers.

Also intrusive because the actual objects get embedded into
things like links directly via the value semantic based template
generation process. That sounds quite intrusive (if not assuming).

Oh, I see what you mean. But there's nothing bad about it. It's
actually very good. The thing is: the container is supposed to manage
the objects of a specific type. Why not storing these objects
directly
as a member of some other "node" object that also contains some links.
(I guess you were thinking about std::list). It doesn't quality as
"intrusive".

in message
He said DISadvantages.
Duh!





Was STL the first to introduce the concept of algorithms working on
containers via iterators?

I don't know. But that's not the point. The point is that the STL
does
so *without* runtime polymorphism which is a big advantage w.r.t. code
optimization.


Cheers!
SG

 

[peter koch]

Was STL the first to introduce the concept of algorithms working on
containers via iterators? If so, then your last statement, though a bit
strong, has some merit (there are other simpler ways that may be appropriate
for a given project and variations on the theme also). If it wasn't the
first to introduce that architecture, then I say the kudos belongs somewhere
else. The implementation, of course, is too obfuscated and complex to be of
"great style and design" even if the algo-iterator-container was first used
in STL (which I doubt, but I can't remember the early stuff anymore, say
Roque-Wave pre-template version, or Borland BIDS, e.g.).

Why do you believe the implementation is obfuscated and/or complex?
That is simply not correct.

/Peter

 

[James Kanze]

this is my understanding of what "intrusive" means:

Example: Intrusive smart pointers: You are required to add the
reference counter to your object you want to manage.

Example: Intrusive Containers: You are required to derive from
a base class for your elements you want to manage.

In both cases you are forced to add some specific code to the
class of your objects. The pointer/container design is
"intruding" your class.

Exactly. That is the generally accepted meaning.

On 21 Mrz., 11:24, "Tony" wrote:

IMHO, that was a bad decision. The generic/value semantics
approach is the most universal one because you can choose to
manage (smart) pointers OR your objects directly.

It depends on the language, but C++ has full support for value
semantics, and considers pointers to be first class objects, so
it does seem a shame to not take advantage of it.

Also you lost type safety by using void*.

Not necessarily, if the void* doesn't perculate up to the
interface of the template. What you do loose is control of the
lifetime of the members; you can (and likely will) end up with
dangling pointers in the container. Basically, you're requiring
the client code to handle lifetime---for complex, entity
objects, this is actually preferable (but then, you'd have a
container of pointers, so that's what you'd get), but for things
like int, it's a recepe for disaster.

[...]
It's the opposite of intrusion. Nothing intrudes into the
objects in the container.

[...]
Certainly not. The concept was around even before C++ was
invented.

I don't know. But that's not the point. The point is that
the STL does so *without* runtime polymorphism which is a big
advantage w.r.t. code optimization.

With regards to "polymorphism" of iterators, there are really
two dimensions (or maybe more): one corresponds to the
value_type of the iterator, and the other to what the iterator
iterates over. Changes in the value_type change the interface
of the iterator; it is now recognized as a serious design error
to make these dynamically polymorphic (i.e. by having the
iterator always return Object*). There is some argument,
however, in favor of using dynamic polymorphism for the type of
the container (i.e. std::vector<double> and std::list<double>
would have the same type of iterator): you can't write a
function in C++ which processes a collection of iterators, some
of which are into vector, some into list, etc. The question in
this case is: how much does it cost, and how often do you want
to do this. And also, what are the side effects (i.e. you can't
use values if the object is to be dynamically polymorphic). The
iterators of my pre-standard containers supported both, and in
practice, the value semantics were used almost exclusively.

 

[James Kanze]

You're assuming that because STL is complex and difficult to
understand immediately that all alternatives are so also.

It would help if you could read English, or would at least read
the message you're responding to. I'm not assuming anything,
except that I'm working on a professional project, with other
people. I'm certainly not assuming that alternatives to the STL
have to be as complicated and as poorly designed as it is: I've
used many class libraries where that wasn't the case. And I've
certainly implemented library components every bit as reliable
as the usual implementations of the STL.

None of which has anything to do with the advantages of being
standard.

Probably also assuming that nothing can be as reliable or
perform as adequately as STL. All wrong assumptions. And what
good is a developer who can't implement say a linked list?
Moreso, what good is a development house or department that
can't? "Standard" an asset?

Obviously, you're not an engineer, and have never had to
develop software that could be maintained by other people.

 

[James Kanze]

Why do you believe the implementation is obfuscated and/or
complex? That is simply not correct.

Well, there is all the allocator stuff, which is probably
unnecessary in most cases. Other than that, though...

Given the design, the typical implementation of the STL stuff is
archi-simple. I'd never design a component library from scratch
to use pairs of iterators, since that makes life too complex for
the user. But it actually simplifies the implementation.

 

[Tony]

Hello Tony,


this is my understanding of what "intrusive" means:

Example: Intrusive smart pointers: You are required to add the
reference
counter to your object you want to manage.

Example: Intrusive Containers: You are required to derive from a base
class for your elements you want to manage.

In both cases you are forced to add some specific code to the class of
your objects. The pointer/container design is "intruding" your class.




IMHO, that was a bad decision.

Opinions vary.

The generic/value semantics approach
is
the most universal one because you can choose to manage (smart)
pointers
OR your objects directly.

I analyzed that. I chose diferently than STL.

Also you lost type safety by using void*.

Shows you don't know what you're talking about. You say that so
"authoritively", but it is, of course (to the knowledgeable), entirely
false. (Hehe, yeah I reveled in that a bit... it's sooo low hanging fruit
knowledge that it is begging to abuse for the fact that it is likely to be
PROPAGANDA).

There's nothing wrong nor intrusive (by the definition I use) with it.
If you don't want copies (because copying is expensive or not
appropriate) and/or runtime polymorphism you could use (smart)
pointers.

I was being flighty about STL: I think it is "intrusive". Assumptive (less
than comprehensively thought out). Wait, oppressive that it/they assumed
they knew my domain of implementation.

Oh, I see what you mean. But there's nothing bad about it.

YMMV, but for me/my code, I assure you that it is more than just a hindrance
(it's completely wrong).

It's
actually very good.

Noted: you are a marketeer. (Anything you say can and will be held against
you ...)

The thing is: the container is supposed to manage
the objects of a specific type.

Look up this word: paradigm.

Look up another: propaganda.

Why not storing these objects
directly
as a member of some other "node" object that also contains some links.
(I guess you were thinking about std::list). It doesn't quality as
"intrusive".

Surely curb this. You are professing "holy grail" of containers and
algorithms. Good luck finding Jesus.

Duh!

A post before that he was "all over the map". It was very annoying.

I don't know. But that's not the point. The point is that the STL
does
so *without* runtime polymorphism which is a big advantage w.r.t. code
optimization.

Ahhh! Now we get to "the point": Muscle cars!

Tony

 

[Tony]

Was STL the first to introduce the concept of algorithms working on
containers via iterators? If so, then your last statement, though a bit
strong, has some merit (there are other simpler ways that may be
appropriate
for a given project and variations on the theme also). If it wasn't the
first to introduce that architecture, then I say the kudos belongs
somewhere
else. The implementation, of course, is too obfuscated and complex to be
of
"great style and design" even if the algo-iterator-container was first
used
in STL (which I doubt, but I can't remember the early stuff anymore, say
Roque-Wave pre-template version, or Borland BIDS, e.g.).

"Why do you believe the implementation is obfuscated and/or complex?"

Because I've analyzed and assessed it.

That is simply not correct.

That's obviously at best an opinion and at worst oppressionistic propaganda.

Tony

 

[Tony]

You're assuming that because STL is complex and difficult to
understand immediately that all alternatives are so also.

"It would help if you could read English, or would at least read
the message you're responding to."

I see, you're still just studying English (nuff said, I'll try to NURSE YOU
WITH A TIT).

"I'm not assuming anything,"

Of course not P).

"except that I'm working on a professional project"

Noted: a "professional" project. Vs. of course me who comes in and clues in
the stakeholders and fires your ass for well known to me a variety of
reasons. I agree: you are probably a part of the "meltdown".

", with other
people."

Of course I'm not one of those. And you have a whole war theory implied.

"I'm certainly not assuming that alternatives to the STL
have to be as complicated and as poorly designed as it is: I've
used many class libraries where that wasn't the case. And I've
certainly implemented library components every bit as reliable
as the usual implementations of the STL."

But you don't do what I do.

"None of which has anything to do with the advantages of being
standard."

There are no advantages to being standard.

Probably also assuming that nothing can be as reliable or
perform as adequately as STL. All wrong assumptions. And what
good is a developer who can't implement say a linked list?
Moreso, what good is a development house or department that
can't? "Standard" an asset?

"Obviously, you're not an engineer, and have never had to
develop software that could be maintained by other people."

Surely, "obviously" because you have said so. So let it be written.

Bitch.

Tony