disadvantages of using STL

[zr]

Q What are the disadvantages of using STL ?

Thanks in advance
Pallav Singh

Since no one mentioned it, what about code bloat? Is this still an
issue in recent implementations?

 

[Noah Roberts]

I would use a combination of the Boost Intrusive containers and the
STL.
Boost Intrusive doesn't have anything like vector or deque so I'd use
those where it made sense. In places where there is a choice between
an STL container and a Boost Intrusive container, I'd favor using the
Boost Intrusive container.

Obviously, nobody saying the STL is a useful tool nor that it exhibits
good design are saying it's the only C++ library that does, nor that
it's necessarily the best thing out there. I've yet to see a single
argument from those who are claiming it's, "too complex," that isn't
some variation of, "I looked at my compiler's implementation and didn't
understand it."

A lot of the boost stuff takes the ideas of STL and expands on them.
Some more than others. People complaining about the STL won't be
impressed by what they find in boost at all. For one thing, the amount
of hacks that have to go into boost in order to make it compatible with
non-standard compliant but important compilers is formidable in many
cases. For another thing, without some familiarity, or at least
willingness to become familiar, with these "academic" methods of design
and implementation that people are complaining about, boost is
completely undecipherable.

 

[Tony]

"Hello Tony,"

No need to be formal (seesh).

"it seems you don't have a lot to contribute to this (or any?)
discussion."

Give to receive. (Or is that too a cliche?).

" I went through the trouble of reading all your posts in
this thread and the thread "C++ is complicated" again and the only
things that have stuck are:"

("only", as if you are omniscient).

"* STL is supposedly complicated."

I said "obfuscated", didn't I?

" It's more complicated than your container library."

From an implementation standpoint, yes. (You're not talking about design
outside of the language/syntax domain are you?) Think about it this way:
why
would I have created and evolved something else if I thought STL was "the
bomb"?

You remind me of "Le Chaud Lapin" on comp.lang.c++.moderated."

The name sounds familiar: he's "all over" threads and IP stacks, right?

"He
goes on and on about his code, but doesn't ever publish it. I asked
him about that a couple years ago and he said he would in a year or
so. I don't know for sure, but I wouldn't be surprised if he hasn't
published anything yet. If you don't have a growing number of users
for your software, I don't think it will mature."

Some of us have too much invested in blood, sweat and tears to divulge any
patentable thing or trade secret at the source code level. You said
"software" and "mature". Did you mean "source code"? Think about it this
way: given what is commonly known (the std library), and using that as just
a starting point, shouldn't you be considering that the std library is
"obsolete" given that many private, commercial and independent researches
have built or are building something else?

" I once thought the
STL was "the bomb," but have changed my mind now. In a number of
ways the containers in the Boost Intrusive library are better than
the STL. Anyway, your talk of another approach without giving much
detail or publishing anything doesn't work for me."

Understood. I wasn't selling my approach/architecture/designs nor divulging
them. If it comes out sometimes, it's because it's where my mind is at and
what I'm doing (or if I'm in the groups I'm procrastinating, needing
sebatical or something similar...).

In many instances, even container choice makes little difference.
Personally, I use a container that fits the problem even if "a simple
array"
could do it more efficiently a lot of times. If I was developing genome
programs or such, I would probably choose the highest performing beast
available: STL (template-based gives high perf).

"I would use a combination of the Boost Intrusive containers and the
STL."

Everytime I visit the Boost site, I don't leave with anything that sticks in
my mind. They must be tailoring to "rocket scientific programming" or
something. (?). (rhetorical, start a new thread if you wanna promote/discuss
Boost).

"Boost Intrusive doesn't have anything like vector or deque so I'd use
those where it made sense. In places where there is a choice between
an STL container and a Boost Intrusive container, I'd favor using the
Boost Intrusive container."

It's been a long time since I've searched for commercial alternative
libraries (when it was just containers/iterators/algos it was easy?).

I think that the concept of
one library that would span the needs of a programmer that needs to
develop
utility programs in adjunct to network/system administration, to the
scientific programmer, a non-practical idea. Rogue-Wave and Borland both
went to "enterprise development". Did they "cave in" because of the C++
std
library? I know how companies evolve. And when the substance walks out the
door (and gets "let go"), the company stagnates to a period of
inter-management boom ("enterprise" sounds kinda fitting huh?).

You're a bit behind the current times though apparently: you are saying
that
if one uses C++, then the std C++ library is the way to go. I don't think
C++ is the way to go and haven't for quite awhile. It has been a great
learning experience, but times have changed.

"What do you suggest? Do tell."

The preceding sentence of mine applies: search on the web for commercial
products, open source tends to have other agenda. You get what you pay for!
That of course must be a lie, because I took time out to (and am taking time
out to) develop from ground up, BUT with the the knowledge of what kind of
software I will build and with ability to do that. There used to be (in many
a "consulting company") a division of "developers": 3GL and 4GL where "4GL"
pretty much meant GUI builders in a point-n-click environment. I feel the
same way about the "blind" users of the std library. They are kinda like the
4GLers. I have other posts to catch up on, but I can map out the scenarios
like reading a book for the 10th time: "high level point n clicker wants to
be the head honcho on the project". Buying AutoCad does not make one an
architect or engineer or project manager. (</soapbox>, I guess). I don't
"suggest" or "give advice" because "I am not a lawyer"-type reasons. What
did I do? What am I doing? I'm building it from scratch. If "you're in the
top 10%", go for it, else consider ... whatever.

Tony

 

[Tony]

Obviously, nobody saying the STL is a useful tool nor that it exhibits
good design are saying it's the only C++ library that does, nor that it's
necessarily the best thing out there. I've yet to see a single argument
from those who are claiming it's, "too complex," that isn't some variation
of, "I looked at my compiler's implementation and didn't understand it."

Or couldn't even SEE it? I'm currently reimplementing my string library (I
haven't touched it yet, but I have all the info now and it's my next "heads
down and code" task). I haven't had my nose in STL for quite some time, I
think I remember that string was a generalization of arrays? (I never looked
at STL string in detail, because I've always used my string: it was one of
the first things I did learning C++; COW and other stuff.... COW and other
stuff removed after assessing the target environments and threading issues).
C and C++ have a fundamentally wrong concept of "character string", IMO, so
how would I not consider that "complex" or any other such term to describe
how over-general thinking produces such monsters?

A lot of the boost stuff takes the ideas of STL and expands on them. Some
more than others. People complaining about the STL won't be impressed by
what they find in boost at all.

I have seen a couple or a few things of paramount importance and much the
rest as highly-C++-specific and even domain-specific (the latter of which
would not be bad except that it is coded in "obfuscated" C++). I think that
a developer (not a commanded one on a project) should take care to avoid
language-isms to be forward-thinking, especially at the domain level (and of
course "domain" has vast range).

For one thing, the amount of hacks that have to go into boost in order to
make it compatible with non-standard compliant but important compilers is
formidable in many cases. For another thing, without some familiarity, or
at least willingness to become familiar, with these "academic" methods of
design and implementation that people are complaining about, boost is
completely undecipherable.

You need to explain "academic design", but it doesn't sound good right and
is probably appropriately named: for academic research.

Tony

 

[zr]

It's never been a problem for me.  If you do find that your performance
is suffering because of unnecessary icache misses, there are
straight-forward techniques to address the problem.  (I've heard the old
technique of partially specializing for all raw pointer types, then
wrapping a non-template implementation that only uses void*, referred to
as "hoisting.")

Do you mean that the client code of STL can workaround this problem? I
always thought that it is STL implementation dependant.

 

[James Kanze]

It's never been a problem for me.

It probably depends on what you're doing. The STL, in general,
has been designed to favor speed when it comes to speed/space
trade offs, and so is probably inappropriate in contexts where
space is extremely restricted. Which doesn't motivate
implementors to reduce the size of the executable.

More generally, however... If you look at the source code for
the STL, you'll find that underneith it all, it's very simple.
There just isn't that much of it. So if you get two copies of
the code when you instantiate two different types (even though
most of it is identical), the code you write using the instances
(which isn't identical) is usually so much bigger that it
doesn't matter.

If you do find that your performance is suffering because of
unnecessary icache misses, there are straight-forward
techniques to address the problem. (I've heard the old
technique of partially specializing for all raw pointer types,
then wrapping a non-template implementation that only uses
void*, referred to as "hoisting.")

So you gain 40 or 50 bytes of code if you instantiate the class
over two different pointer types, but you still have maybe 100KB
of user code using each instantiation.

 

[coal]

Some of us have too much invested in blood, sweat and tears to divulge any
patentable thing or trade secret at the source code level. You said
"software" and "mature". Did you mean "source code"?

Possibly. I'm not sure how you'll be able to sell anything
the way you are going, but I guess you can use your tools
yourself for the time being and hold out.

Think about it this
way: given what is commonly known (the std library), and using that as just
a starting point, shouldn't you be considering that the std library is
"obsolete" given that many private, commercial and independent researches
have built or are building something else?

The std library has containers, algorithms, iterators, string,
streams and more. I've shared my opinion on the containers
here already. My preferred string is flex_string. And I
know that too much of iostreams and your code will be slow.
That leaves the algorithms and vector/deque. So I agree
with you to an extent. But you talk about getting what
you pay for. I don't know of any commercial containers
or strings that are better than the free ones.

 " I once thought the
STL was "the bomb," but have changed my mind now.  In a number of
ways the containers in the Boost Intrusive library are better than
the STL.  Anyway, your talk of another approach without giving much
detail or publishing anything doesn't work for me."

Understood. I wasn't selling my approach/architecture/designs nor divulging
them. If it comes out sometimes, it's because it's where my mind is at and
what I'm doing (or if I'm in the groups I'm procrastinating, needing
sebatical or something similar...).


"I would use a combination of the Boost Intrusive containers and the
STL."

Everytime I visit the Boost site, I don't leave with anything that sticks in
my mind. They must be tailoring to "rocket scientific programming" or
something. (?). (rhetorical, start a new thread if you wanna promote/discuss
Boost).

I like some of the libs in Boost.

"Boost Intrusive doesn't have anything like vector or deque so I'd use
those where it made sense.  In places where there is a choice between
an STL container and a Boost Intrusive container, I'd favor using the
Boost Intrusive container."

It's been a long time since I've searched for commercial alternative
libraries (when it was just containers/iterators/algos it was easy?).




"What do you suggest?  Do tell."

The preceding sentence of mine applies: search on the web for commercial
products, open source tends to have other agenda. You get what you pay for!

If I interpret pay to mean spend time researching, I guess
that makes sense, but if you mean paying money for a library,
I'm not convinced I'd be getting something better than what is
free. Most of the libraries people want money for are worse/
no-better than the free alternatives.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Tony]

Some of us have too much invested in blood, sweat and tears to divulge any
patentable thing or trade secret at the source code level. You said
"software" and "mature". Did you mean "source code"?

"Possibly. I'm not sure how you'll be able to sell anything
the way you are going, but I guess you can use your tools
yourself for the time being and hold out."

I'm not developing tools for developers or source code for anyone. My goal
is shrinkwrap and value-add to other "services".

Think about it this
way: given what is commonly known (the std library), and using that as
just
a starting point, shouldn't you be considering that the std library is
"obsolete" given that many private, commercial and independent researches
have built or are building something else?

The std library has containers, algorithms, iterators, string,
streams and more. I've shared my opinion on the containers
here already. My preferred string is flex_string. And I
know that too much of iostreams and your code will be slow.
That leaves the algorithms and vector/deque. So I agree
with you to an extent. But you talk about getting what
you pay for. I don't know of any commercial containers
or strings that are better than the free ones."

"better" is a subjective term. I tend to think that perhaps you do not yet
know what your requirements are so you err on the side of something very
general like the std library rather than something you build (indeed, I
think all alternatives are probably very general also, just of different
design). YMMV (I say that a lot, because it's an important realization).
Perhaps all developer-wannabes should in their curriculum (RE)develop all of
the rusty stuff: std libraries, compilers, etc.

"Boost Intrusive doesn't have anything like vector or deque so I'd use
those where it made sense. In places where there is a choice between
an STL container and a Boost Intrusive container, I'd favor using the
Boost Intrusive container."

It's been a long time since I've searched for commercial alternative
libraries (when it was just containers/iterators/algos it was easy?).




"What do you suggest? Do tell."

The preceding sentence of mine applies: search on the web for commercial
products, open source tends to have other agenda. You get what you pay
for!

"If I interpret pay to mean spend time researching, I guess
that makes sense, but if you mean paying money for a library,
I'm not convinced I'd be getting something better than what is
free. Most of the libraries people want money for are worse/
no-better than the free alternatives."

Look at it this way: if you wanted to build something as general as
possible, meaning that it works all the time and for everyone, rather than
just what you need, you'd a staff and a lot of time. Don't over-think it:
you could waste a lot of time. Sometimes, judicious iteration is more
efficient than going in and out of "analysis paralysis". I think I may be
noticing a problem of developers using the std libraries as a STARTING
point, just like those wishing to be architects/engineers wrongly assume
that just buying AutoCad or ProEngineer will make them so. Apparently, "the
industry common knowledgebase" is just one step beyond Cormen and Knuth
(implementing the algos they specified).

Tony

 

[Helge Kruse]

Q What are the disadvantages of using STL ?

It's sometimes clumsy in a multithreaded environment.

Helge

 

[Tony]

The STL was designed originally by Alex Stepanov, not by
committee. Anyway, that's not a meaningful answer, just a
cliche that reiterates your opinion that standardization is
inherently detrimental. Are you saying that your dislike of
STL is more philosophical than technical?

"If I understand him correctly,"

You're a programmer, a good one perhaps, but everything I've ever seen you
post has been at that same level. Fine, you're a specialist. Perhaps you
suck at design/architecture/cross-functional-project-mgmt. Then why would
you "understand me"?

" he's saying that the STL is too
complicated for him to understand"

Ad hominem. I evaluate(d) STL just like any other product. I had used it in
the past and other libraries also, but I refuse to join your pissing
contest. You use STL and promote/marketeer/propagandize it, I avoid it for
reasons given and other reasons that I don't feel the need to give.

", that he's capable of
designing and implementing something far better, and that he's
not going to tell anyone how or what."

That is telling about YOU: you seem to think that there is always a "one and
only" solution. Black and white. No gray. Etc. If the shoe fits, and it
seemingly does, wear it.

"You figure out if that makes any sense."

Surely you mean your propaganda.

" From his postings, I
gather that he doesn't understand beans about software
engineering."

I ain't biting. Go fishing elsewhere.

" (To whit: it doesn't really matter how well
designed you find the STL"

Meaningless false generality.

"---it's standard,"

No, just branded. Being opportunistic in time is not a revered
characteristic, but a hated one.

" it's what people know
and understand,"

It's what a limited subset of the potential set could know and understand,
it's C++-specific and slows progress.

" and it is sufficient in most cases,"

PT Barnum once said...

" so it's what
you use."

If you are a slave to the comittee. (Ref to past repressive governments
omitted).

" Whatever it's intrinsic qualities or defaults.)"

No one doesn't. As I haven't. If you just want a club card and decoder ring,
go for it. Else go find a real job or start from scratch or...

Tony

 

[Tony]

It's never been a problem for me.

"More generally, however... If you look at the source code for
the STL, you'll find that underneith it all, it's very simple."

"Duh": just go read Cormen's book on algos (or anything similar, but NOT
Knuth (too forced-mathematical, the trend at the time, just like in database
theory).

"There just isn't that much of it."

Read STL has no substance: the underlying language-independent algorithms
are the substance.

" So if you get two copies of
the code when you instantiate two different types (even though
most of it is identical), the code you write using the instances
(which isn't identical) is usually so much bigger that it
doesn't matter."

It's one thing to choose to use a given algorithm (I use the term loosely)
to implement a higher level "container", it is quite another to commit to
using the C++'d version of it.

If you do find that your performance is suffering because of
unnecessary icache misses, there are straight-forward
techniques to address the problem. (I've heard the old
technique of partially specializing for all raw pointer types,
then wrapping a non-template implementation that only uses
void*, referred to as "hoisting.")

"So you gain 40 or 50 bytes of code if you instantiate the class
over two different pointer types, but you still have maybe 100KB
of user code using each instantiation."

Space and time are not the only concerns. (But apparently some people like
to use that smoke-and-mirrors approach).

Tony

 

[Tony]

Did you reply to the wrong post?

Quite possibly/possible!! (I'm pretty lax in newsgroups. I don't even
usually notice who I'm responding to, as I'm only interested in the tech
info and how technical things came to be. Sometimes I am facetious and play
"devil's advocate". Many times, the best way to find out about a system is
to perturb it (a fundamental technique of ME)).

Tony