STL popularity?

[Gregory L. Hansen]

I'ld say that the figure is closer to 65%-70% judging by those programmers
i've met that do code at least partly with C++. Whats certain is that many
of the remaining suffer from poor coding concepts and weak discipline which
the standard imposes on those who do choose to implement it.

STL is well-worth the learning curve even if you chose not to use it. It
doesn't take long for an experienced C++ programmer with STL knowhow to spot
one without it. Add to this the fact that STL's OO concepts and attention to
detail changes how you program in other languages and the benefits stack-up
quickly.

That's some pretty amazing praise for STL.

I'm sort of a novice and a weekend warrior when it comes to programming,
but I've avoided the STL at first. Iterators confused me, I was
suspicious of trusting my data to those little black boxes. But dang, how
many times do I have to make my own linked lists, or dynamically resize my
arrays, before it sinks in that the work has already been done for me?

And now you have me wanting to look for excuses to use STL, for the
instructional value.

 

[Angad]

Well, I would say that the code took SIGNIFICANTLY more compile time
compared to pointer implementation
Performance-wise, I think there wasn't much difference (of course, we
never reached a scale of input where we could observe any difference).

 

[Mike Wahler]

What will you do with the responses?

Probably store them in a container.

-Mike

 

[codigo]

That's some pretty amazing praise for STL.

Its more a praise for C++, really. a templated class can encapsulate an STL
container. So that class can contain practically anything you throw at it.
Using whatever interface you are most comfortable with.

I'm sort of a novice and a weekend warrior when it comes to programming,
but I've avoided the STL at first. Iterators confused me, I was
suspicious of trusting my data to those little black boxes. But dang, how
many times do I have to make my own linked lists, or dynamically resize my
arrays, before it sinks in that the work has already been done for me?

The array issue is one i might be able to help you with. In release mode, a
std::vector with an appropriate reserve or a std::deque will outperform an
array even if the array isn't resized. The larger the dataset, the higher th
e benefit.

And now you have me wanting to look for excuses to use STL, for the
instructional value.

I know a bunch who prefer making their own containers. Where the STL
deserves credit, in so far as instructional value is concerned, is best
explained by considering a forward iteration (for example) through a
std::vector and a std::queue. Its the exact same procedure for both, not to
mention most other STL containers. So the value is obvious.

 

[Gerry Quinn]

I dont see it as hype. I can one or two things I would like in the standard
(hash containers, slist (and preferably with Dinkumware style iterators
rather than SGI), rope, is_sorted(), is_heap(), a few other algorithms, some
of the boost binders, unique_pointers (or smart_pointers), move semantics)
but I see at my place of work (over 13,000 people), dozens of programmers
using the STL for "real world projects". In fact I think one of our "real
world projects" used by many clients might well abandon MFC container
classes and use container classes out of the standard as they are better
designed.

Indeed, I found the MFC container classes easier to understand
initially, but I now prefer the stl ones.

I still use CString though!

- Gerry Quinn

 

[Gerry Quinn]

I'ld say that the figure is closer to 65%-70% judging by those programmers
i've met that do code at least partly with C++. Whats certain is that many
of the remaining suffer from poor coding concepts and weak discipline which
the standard imposes on those who do choose to implement it.

STL is well-worth the learning curve even if you chose not to use it. It
doesn't take long for an experienced C++ programmer with STL knowhow to spot
one without it. Add to this the fact that STL's OO concepts and attention to
detail changes how you program in other languages and the benefits stack-up
quickly.

If either of the above paragraphs were correct, they would constitute a
good reason to avoid STL. Fortunately they are not.

STL is a powerful library, and the more useful parts of it are easy to
learn.

If there are parts that are hard to learn or use, they are best ignored
until such time as they are fixed.

- Gerry Quinn