disadvantages of using STL

[SG]

Opinions vary.

Sure. We could agree to disagree. But ...

I analyzed that. I chose diferently than STL.

.... you could also explain WHY you chose so since I gave a reason why
I think the STL approach is the better one.

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.

Right back at you. I could say the same thing to you. What's
probably more productive is telling us something about your design.
Like James Kanze wrote, you can use void* internally and use a
templated-interface that statically casts your pointers so that the
area you can screw up is restricted to the implementation details of
your container. But how should I know what your design looks like? I
was under the impression that you don't like templates.

Are you even interested in discussing this or do you just like to
demonstrate your superiority?

[speech about propaganda removed]

If you don't want copies (because copying is expensive or not
appropriate) and/or you want 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.

What's your definition of intrusive then and more importantly why is
it such a bad thing (in this case)?

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

That's not enough to convince me, really. Can you shed some more
light on this? Maybe give an example + arguments about it being a bad
design?

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

Oh, please! Stop this. Can't you discuss a topic without attacking
someone personally?

Look up this word: paradigm.
Look up another: propaganda.

This is not very constructive at all. I assure you I'm quite capable
of accepting advice, admitting knowledge gaps, etc. But so far you
havn't said anything interesting.

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

We get it. For you "intrusive" means something different. Still, you
haven't pointed out the weakness of this design or gave ANY argument
whatsoever. You merely generated noise. Frankly, this is the
behaviour I would expect from a crank.

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

I'm sure that's not the only good argument. But at least it's a good
one. Why do you want to pay for something you don't need? Even if it
turns out to be the only argument, what's bad about it?

What does TonyVector<int> do? Or is it just TonyVector (no template)
that accepts void*?


awaiting some constructive content,
SG

 

[Tony]

Opinions vary.

Sure. We could agree to disagree. But ...

I analyzed that. I chose diferently than STL.

.... you could also explain WHY you chose so since I gave a reason why
I think the STL approach is the better one.

You're right, I could. Of course.

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.

"Right back at you. I could say the same thing to you. What's
probably more productive is telling us something about your design.
Like James Kanze wrote, you can use void* internally and use a
templated-interface that statically casts your pointers so that the
area you can screw up is restricted to the implementation details of
your container. But how should I know what your design looks like? I
was under the impression that you don't like templates.

Are you even interested in discussing this or do you just like to
demonstrate your superiority?"

Hmm.

[speech about propaganda removed]

If you don't want copies (because copying is expensive or not
appropriate) and/or you want 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.

"What's your definition of intrusive then and more importantly why is
it such a bad thing (in this case)?"

Hmm.

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

"That's not enough to convince me, really. Can you shed some more
light on this? Maybe give an example + arguments about it being a bad
design?"

Hmm.

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

"Oh, please! Stop this. Can't you discuss a topic without attacking
someone personally?"

Hmm.

Look up this word: paradigm.
Look up another: propaganda.

"This is not very constructive at all. I assure you I'm quite capable
of accepting advice, admitting knowledge gaps, etc. But so far you
havn't said anything interesting."

Hmm.

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

"We get it. For you "intrusive" means something different. Still, you
haven't pointed out the weakness of this design or gave ANY argument
whatsoever. You merely generated noise. Frankly, this is the
behaviour I would expect from a crank."

Hmm.

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

"I'm sure that's not the only good argument. But at least it's a good
one. Why do you want to pay for something you don't need? Even if it
turns out to be the only argument, what's bad about it?"

Hmm.

"What does TonyVector<int> do? Or is it just TonyVector (no template)
that accepts void*?"

Hmm.


Tony

 

[peter koch]

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

Because I've analyzed and assessed it.

And so did I. The code in general is simple and quite straight-
forward.

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

The opinion occured in the post I responded to. You claimed that your
version of the standard library was complex and obfuscated.

/Peter

 

[Guest]

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.

it contains a lot of examples as well. It's much easier going than
other books I've tried (Musser et al springs to mind)

 

[Noah Roberts]

"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

Hey Tony, I'd suggest fixing your quoting format. It's impossible to
tell where the quoted text ends and your response begins because you are
not using any quote character.

 

[Noah Roberts]

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

Probably, at least for C++. Stepanov is at the front line of generic
programming in C++: http://www.stepanovpapers.com/

Visitors where around for ages before that though.

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

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

 

[Noah Roberts]

He said DISadvantages.

Oh.

 

[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

Hey Tony, I'd suggest fixing your quoting format. It's impossible to tell
where the quoted text ends and your response begins because you are not
using any quote character.

I don't think it is my problem. It's Microsoft's and those who post with
extended ASCII (?).

Tony

 

[Tony]

Oh.

Are you being sarcastic or real? You previous post was so all-over-the-map
that I didn't respond to it.

 

[James Kanze]

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

It depends on whether you want your code to be read by other
people or not. If you're just working in a vacuum, for your own
pleasure, it doesn't matter. If you're producing code in a
professional environment, where the code has to be reviewed, and
other people will have to maintain and modify it, using
something standard (in the sense of universally known and
understood) is an enormous advantage---if there is a standard
solution, then you should only do something else if there are
very powerful reasons for not using the standard.

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

I don't understand the question. If it's standard, it's not
house specific---a new hire won't be familiar with anything
that's house specific. If it's commercial, it depends---a lot
of our software is based on Posix, and we expect new hires to be
as familiar with Posix as with C++, for example. More
generally, if the "commercial" product is widely enough used
that you can reasonably require experience with it for new
hires, fine. In all cases, it's a question of price/benefits: I
can quite understand firms adopting wxWidgets or Qt, for
example, even though they probably can't expect every new hire
to be familiar with it---there is no truely "standard"
alternative, and the benefits of using an already written
library are enormous. In most cases, however, the standard
library is good enough, and since anyone who claims knowledge of
C++ should be familiar with it, it's the way to go. In special
cases, however, there may be justification for something
different: a numerics application will probably prefer an in
house matrix class to std::vector< std::vector< double > >
(although it would almost certainly use std::vector in the
implementation), and a text processing program will doubtlessly
have its own "text" class (certainly based on std::string,
unless the profiler says no later).

 

[Tony]

And so did I. The code in general is simple and quite straight-
forward.

After unobfuscation MAYBE. Even then though, not as clear as it could be. (I
extract algos from STL for use in my own code where I need a quick starting
point: It's painful).

The opinion occured in the post I responded to. You claimed that your
version of the standard library was complex and obfuscated.

Well maybe I did do that. I haven't used it in so long that I forget.
Borlands wouldn't compile easily. STLPort did, but was hardly ripe for
picking off the fruit. That's pretty much what I consider STL: SGI STLPort.
While I haven't been doing container algo development in a few years (I'll
be going back there to fill the holes though), I still have the HP sources
to look at that are much more comprehensible.

Tony

 

[Tony]

Probably, at least for C++.

That wouldn't count then if it was just grafted onto C++: no invention.

If so, then your last statement, though a bit


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

It's not, but of course I'm not going to eval and assess "competitor"
product to further the point.

 

[James Kanze]

Oh.

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.

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.

 

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

"It depends on whether you want your code to be read by other
people or not."

No it does not. You're doing the "assume god before proving god" thing. Std
C++ is not easy to read. But it can be. So I am saying that the style makes
more difference than the language. I think you may be saying that because
the common use of the language is cryptic, that is acceptable. I've had long
time Cobol programmers see my code and say: "that's easy! I can do that!".
It wasn't C++. It was my API or stylistic usage of the tool that could
grasp. All the details were hidden. Without going too far into hypothetical
land, there's a goodness aspect of computer language design in regards to
usage that is lacking with the concept (or just implementation?) of a "close
to the machine", "GP" language.

"If you're just working in a vacuum, for your own
pleasure, it doesn't matter."

But that's not true either: you're assuming some global coding style and
that does not exist. And just specifying the language is less important than
the "how" it is used. Your statement above is extreme. There is an entire
range of possibility between using an API written in C++ and having no rhyme
or reason/starting from scratch. I can't help but think you are on the
"start from scratch" position and that you feel that "have C++ std, will
travel" is adequate. Note that I say that is woefully inadequate. The C++
std doesn't even get one to level zero. There is SO much to be built before
you can even create a program: tooling up is necessary.

" If you're producing code in a
professional environment, where the code has to be reviewed, and
other people will have to maintain and modify it, using
something standard (in the sense of universally known and
understood) is an enormous advantage"

But that doesn't exist. Not at the level you suggest: that C++ std is that
thing. It's not. It's trees vs. paper. (Well maybe if you have Birch bark).

"---if there is a standard"

"IF" is the keyword in that statement.

"solution, then you should only do something else if there are
very powerful reasons for not using the standard."

Now you're arguing the std lib? That's such a small part of it. And using it
ties software to C++ more tightly than desireable (You don't think C++ is
the end do you? I'd say it's now obsolete for new development, save for that
quite obviously better language even largely based upon it).

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

"I don't understand the question."

OK, but you didn't prune enough context to let me remember my thought. Hang
on... OK. Surely I meant that STL and the std lib is no better than any
other proven lib. You can only use time as a quality-producing measure at
the beginning of a development. It is a much used general "argument" though.
It has no teeth. Evolve something else in house or across a commercial
ecosystem and it will be better for a given use or for a given team (that's
your scenario), or a given software house or a given shrink-wrap house...
see what I'm saying? It's not just containers and algos and iterators. Other
things are directly related. Do you really want to suggest that some
homogenous "std" library is ideal? You have to look at the software
development environment: you're hoping for plug-n-play team members on SW
dev projects, but I assure you that it does not exist at the language level
and shouldn't. I can go on, but you get my point.


" If it's standard, it's not
house specific---a new hire won't be familiar with anything
that's house specific. "

See, you're dismissing the product-producing software or solution provider
in favor of low level technical detail. You may do it that way, teach
deliverable team members std C++ and such, I've done that, I aspire to
deliver shrink wrap. (I already do, but only to my consulting clients who
just want it done and use my software daily without even knowing it). I'm
solution focused rather than technology focused. I'm aspiring to get to a
higher level of solution and plugging away almost daily at my codebase. I'm
to the level now that I'm chomping at the bit of specifying and implementing
(latter is harder) my own language. Not just DSL either (it's mostly why I'm
on USENET again: R&D).

"If it's commercial, it depends---a lot
of our software is based on Posix, and we expect new hires to be
as familiar with Posix as with C++, for example. More
generally, if the "commercial" product is widely enough used
that you can reasonably require experience with it for new
hires, fine."

Again, I know that is too low level to be "standard". So I've said the ISO
committee should get out of the library business. A reference implementation
is all good. But a centralized implementation unextricable from the
paradigms of C++? No thank you. I consider that "boiling in oil" tactic. If
you want to talk standardization, I think you have to talk least common
denominator as a starting point.

"In all cases, it's a question of price/benefits:"

Don't forget the time component: short term vs. long term. Is it a
"consultancy" project team? A solution provider? A shrinkwrap software
house? These are all very different environments that can and should use C++
in different ways if they use C++ and THE AMOUNT OF TOOLING UP they do
before starting. C++ is not a tool. It's something to build tools from. It's
iron ore, rather than a sword.

" I
can quite understand firms adopting wxWidgets or Qt, for
example, even though they probably can't expect every new hire
to be familiar with it---there is no truely "standard"
alternative, and the benefits of using an already written
library are enormous."

That's not true. You're assuming an environment of use.

"In most cases, however, the standard
library is good enough,"

That's unproven rhetoric. Being first to market doesn't ensure being best at
anything.

" and since anyone who claims knowledge of
C++ should be familiar with it, it's the way to go."

That's not true either. Style, API and tooling up are much more important
than language. Architecture, design...

" In special
cases, however, there may be justification for something
different"

No, I disagree: as we know with C and C++, standards in languages and
libraries are stifling. New development is stifled by a standard that is
unnecessarily (for the scenario) "backward compatible. You know what it is
akin to? Putting code into the source control system too early. That is
indeed the C/C++ legacy. Trying to be a standard before it's even in
puberty.

" : a numerics application will probably prefer an in
house matrix class to std::vector< std::vector< double > >
(although it would almost certainly use std::vector in the
implementation), and a text processing program will doubtlessly
have its own "text" class (certainly based on std::string,
unless the profiler says no later)."

That's quite micro-level thought. It's important, but not in the outer
scope. Sure, someone has to "twiddle bits". If there is nothing beyond that
in a project, plan or argument, well, it's pretty much the Lord of the Flies
scenario.

Tony

 

[Tony]

Oh.

"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 be
more efficient than any non-template or "partially templatized" version in
regards to program PERFORMANCE. But now that we're talking about it, in most
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-Kutta
physics stuff, but scientific calculation is hardly the norm.

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

Tony

 

[SG]

Hi Tony,

I was just alluding to the fact that the template-based STL is going to be
more efficient than any non-template or "partially templatized" version in
regards to program PERFORMANCE. But now that we're talking about it, in most

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

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-Kutta
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?

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

 

[Noah Roberts]

After unobfuscation MAYBE. Even then though, not as clear as it could be. (I
extract algos from STL for use in my own code where I need a quick starting
point: It's painful).

You seem to be making a rather common and basic mistake: associating
implementation with design.

Anyone can obfuscate a design in their implementation.

 

[coal]

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

I take it by efficiency you mean programmer efficiency. Boost
Intrusive is more efficient runtime-wise than the STL.
Development using Boost Intrusive containers takes more time
for most of us than using the STL, but the customers will get a
better performing application. Eventually, presumably, we'll
get the hang of Boost Intrusive.

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.

This kind of assumes dull customers who don't check out the
competition. If that's the case, I wouldn't feel sorry for
them.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net


Rabbi Tarfon said: The day is short, the task is great, the
laborers are lazy, the wage is abundant and the master is urgent.

He used to say: It is not incumbent upon you to finish the task.
Yet, you are not free to desist from it.

 

[James Kanze]

I take it by efficiency you mean programmer efficiency.

It's the most important kind. But in this case, I was
responding somewhat humorously---the original poster asked for
the disadvantages of the STL, so I suggested that one might be
that it increases programmer efficiency (and thus reduces the
length of the contract).

[...]

This kind of assumes dull customers who don't check out the
competition. If that's the case, I wouldn't feel sorry for
them.

Yes. On the other hand, I've seen a couple of cases in my
career where a software company or a consultant has
(intentionally?) written code that no one else could understand,
and then lived of over priced maintenance contracts for the rest
of the programs lifetime.

 

[coal]

I take it by efficiency you mean programmer efficiency.

It's the most important kind. But in this case, I was
responding somewhat humorously---the original poster asked for
the disadvantages of the STL, so I suggested that one might be
that it increases programmer efficiency (and thus reduces the
length of the contract).

[...]

I figured that, but didn't think it was right to omit the Boost
Intrusive library. I've started using it and like it.
Here are the first three times from executing the same request
with a version that uses the _Rb_tree class that underpins
std::set in a number of places:
ExecuteRequest took 56176
ExecuteRequest took 780
ExecuteRequest took 609

And here they are with a version that replaces three of
those uses with intrusive::rbtree.

ExecuteRequest took 43067
ExecuteRequest took 621
ExecuteRequest took 581

While I'm happy to be able to start using this library,
I still dislike the way the intrusive library wants to
reuse names like list and set/multiset. So I'm glad it
has a class called rbtree and would like to point it out
to others. Just as using _Rb_tree appealed to me
previously, I find (well, I haven't tried intrusive::set)
that the parallel makes sense here. Besides having a
nice interface, there won't be any confusion around the
name as the standard doesn't have an rbtree class and if
they add one they should call it rb_tree or something
other than rbtree. Besides testing it out internally,
I hope to have support for rbtree in the C++ Middleware
Writer as well.

Yes. On the other hand, I've seen a couple of cases in my
career where a software company or a consultant has
(intentionally?) written code that no one else could understand,
and then lived of over priced maintenance contracts for the rest
of the programs lifetime.

It seems like there should be a term for that. When I was
younger a coworker told me there are two kinds of programmers:
plumbers and pretenders. Our team lead was a pretender that
caused some grief. I've noticed what you are referring to as
well, even by people I consider to be very intelligent.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net