STL popularity?

[Norm Matloff]

Anyone have an answer--just a guess would do--as to what percentage of
programmers who do their primary work in C++ make use of the STL?

Norm Matloff

 

[Ron Natalie]

Anyone have an answer--just a guess would do--as to what percentage of
programmers who do their primary work in C++ make use of the STL?

100% of the ones who know what they are doing do. It's hard to write
C++ code and not use some part of the standard library (if that's what
you meant by STL).

Back around the time before the standard was adopted a lot of the
compilers had really sucky implementations of the STL concepts. We
used a combination of roll-our-own and then moved to public STL
impelementations. But as soon as Microsoft, Sun, and the GCC folks got
on with reasonably compliant versions we reverted to the native library
implementations. All those who work for me use the standard constructs
when ever possible, we eschew use of naked new and char*'s.

 

[osmium]

100% of the ones who know what they are doing do. It's hard to write
C++ code and not use some part of the standard library (if that's what
you meant by STL).

Back around the time before the standard was adopted a lot of the
compilers had really sucky implementations of the STL concepts. We used
a combination of roll-our-own and then moved to public STL
impelementations. But as soon as Microsoft, Sun, and the GCC folks got on
with reasonably compliant versions we reverted to the native library
implementations. All those who work for me use the standard constructs
when ever possible, we eschew use of naked new and char*'s.

 

[Stephen Howe]

Anyone have an answer--just a guess would do--as to what percentage of

programmers who do their primary work in C++ make use of the STL?

I should think it is pretty close to 100%.
99.8% would be close.

IMO, the STL was the greatest addition to C++. And Stepanov would not have
been able to "realise" his vision without the flexibility provided in terms
of C++'s template support. It would have been stillborn. The language _had_
to provide the facilities.

And one measure of the success is the fact that there is now "Java Generics"
and "C# Generics" - other languages want to add something of the same.

The other measure of success is the fact that novice C++ programmers are
using these all the time. They are stuffing int's, double's, their own
classes into these containers and using the various algorithms provided.

If Move Constructors get the go ahead for the next C++ standard, then
vectors, etc will become even faster for some types.

Stephen Howe

 

[Phlip]

Anyone have an answer--just a guess would do--as to what percentage of
programmers who do their primary work in C++ make use of the STL?

What will you do with the responses?

 

[Alvin Beach]

Anyone have an answer--just a guess would do--as to what percentage of
programmers who do their primary work in C++ make use of the STL?

Norm Matloff

I tend not to use the STL. Not that I don't like the STL but for my needs, I
require light weight containers. In the past, the STL had the reputation of
being bloated and slow. I must admit though, I haven't looked into the
recent STL implementation recently.

Anyone else who have thought this way but have learned differently, perhaps
you can share your thoughts.

Thanks,

Alvin

 

[Wiseguy]

Anyone have an answer--just a guess would do--as to what percentage of
programmers who do their primary work in C++ make use of the STL?

at the risk using a blasphemous analogy...

c++ without STL is like java with only the java.lang package. you simply
need if if you're going to do anything other than "hello world"

 

[Phlip]

I tend not to use the STL. Not that I don't like the STL but for my needs, I
require light weight containers. In the past, the STL had the reputation of
being bloated and slow. I must admit though, I haven't looked into the
recent STL implementation recently.

That's the advanced answer.

The answer for a beginner: The number one resource to optimize is programmer
time. Don't worry about what's slow, because you will never be able to
predict it. Don't indulge in "premature optimization".

To get your project started quickly, use the most widely supported and
standardized things possible. This will boost programmer time, without
researching rare libraries (or writing them).

Only after you profile your code to see where it's slow, and only after
getting a charter from your customer to spend time optimizing, should you
speed a program up. This may or may not involve replacing Standard Library
things with hand-written, faster things.

And in the specific case of the STL container libraries, you have a wide
range of options, including changing compiler settings, adding new
allocators, changing the template parameters, and changing the container
algorithms, before abandoning STL entirely.

 

[Old Wolf]

make use of the STL?

100% of the ones who know what they are doing do. It's hard
to write C++ code and not use some part of the standard library
(if that's what you meant by STL).

There's a language called "Embedded C++", which is C++ without
templates, namespaces, and all the other useful features.
There are commercial companies which support this language,
therefore there must be a decent user base for it.

Back around the time before the standard was adopted a lot of
the compilers had really sucky implementations of the STL concepts.

It's quite possible to write a large GUI application using
Borland's suite of GUI components and container classes,
and not using any non-C library functions.

Inferior to STL usage of course, but if you already had
a correctly-written non-STL application, why change it?

 

[Jon Harrop]

Anyone have an answer--just a guess would do--as to what percentage of
programmers who do their primary work in C++ make use of the STL?

When I my primary work in C++ I used the STL extensively, both the built-ins
and my own extensions. I've found something better now though...

 

[Hang Dog]

There's a language called "Embedded C++", which is C++ without
templates, namespaces, and all the other useful features.
There are commercial companies which support this language,
therefore there must be a decent user base for it.




It's quite possible to write a large GUI application using
Borland's suite of GUI components and container classes,
and not using any non-C library functions.

Inferior to STL usage of course, but if you already had
a correctly-written non-STL application, why change it?

Our container classes, string, smart pointers, etc were built using the
macros from generic.h back in 1992-1994. By the time the STL stablised
and back then templates were buggy from platform to platform, we had
1,000,000s of lines of code written using our hand rolled lists, sets,
maps, arrays, smart pointers etc. There is no incentive for us to
convert to the STL containers.

 

[Howard Hinnant]

If Move Constructors get the go ahead for the next C++ standard, then
vectors, etc will become even faster for some types.

It is looking pretty good at the moment. The EWG has forwarded the
language part of the proposal to the CWG for review. The LWG has given
a tentative nod towards the library part of the proposal and requested
detailed proposals for the library components.

-Howard

 

[Pete Becker]

It is looking pretty good at the moment. The EWG has forwarded the
language part of the proposal to the CWG for review. The LWG has given
a tentative nod towards the library part of the proposal and requested
detailed proposals for the library components.

Well, yes, but the PRM has SOA'ed it, so unless RTP decides to forward
it to the GAR we'll run out of TLA's.

For those who aren't up on the TLA's, EWG is the Evolution Working
Group; CWG is the Core [language] Working Group; LWG is the Libraries
Working Group; and TLA is three-letter abbreviation.

Sorry, Howard, couldn't resist. <g>

 

[codigo]

Anyone have an answer--just a guess would do--as to what percentage of
programmers who do their primary work in C++ make use of the STL?

Norm Matloff

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.

 

[Angad]

Well, I'm an undergrad, and I'll tell you about the scenario in our
institute.
We've got a lab course in compilers and we had to implement stuff like
parsers - taking input as grammar and generating parse tables -
Top-down, SLR, CLR, etc. in C++. Most of the guys started implementing
linked list classes and everything from scratch - most codes ran into
thousand lines... Then, a bunch of friends and I thought of using STL,
and we used vectors for the implementation. the code reduced to
one-tenth on an average... and ever since, STL has spread like an
epidemic in my class.
So, you see, It's just a matter of awareness - If anyone knows STL,
he's bound to use it

 

[Alvin Beach]

Well, I'm an undergrad, and I'll tell you about the scenario in our
institute.
We've got a lab course in compilers and we had to implement stuff like
parsers - taking input as grammar and generating parse tables -
Top-down, SLR, CLR, etc. in C++. Most of the guys started implementing
linked list classes and everything from scratch - most codes ran into
thousand lines... Then, a bunch of friends and I thought of using STL,
and we used vectors for the implementation. the code reduced to
one-tenth on an average... and ever since, STL has spread like an
epidemic in my class.
So, you see, It's just a matter of awareness - If anyone knows STL,
he's bound to use it

That's interesting. How was the performance between the two implementations?
Or were they about the same?

Thanks,

Alvin

 

[Wiseguy]

Angad wrote:
That's interesting. How was the performance between the two implementations?
Or were they about the same?

If you consider a "bug" or incorrent behavior as a hit to your
performance metric then I'm sure the STL ranks at least as good, if
not better.

 

[Howard Hinnant]

It is looking pretty good at the moment. The EWG has forwarded the
language part of the proposal to the CWG for review. The LWG has given
a tentative nod towards the library part of the proposal and requested
detailed proposals for the library components.

Well, yes, but the PRM has SOA'ed it, so unless RTP decides to forward
it to the GAR we'll run out of TLA's.

For those who aren't up on the TLA's, EWG is the Evolution Working
Group; CWG is the Core [language] Working Group; LWG is the Libraries
Working Group; and TLA is three-letter abbreviation.

Sorry, Howard, couldn't resist. <g>

Thanks for the clarification AND the chuckle.

-Howard

 

[Roland Pibinger]

I should think it is pretty close to 100%.
99.8% would be close.

Really? I think 10-15% use STL in real-world projects. STL is
complicated, inconvenient, and bloated. That's why it's not used more
frequently, despite the permanent hype during the last 10 years.

Best wishes,
Roland Pibinger

 

[Stephen Howe]

Really? I think 10-15% use STL in real-world projects. STL is

complicated, inconvenient, and bloated. That's why it's not used more
frequently, despite the permanent hype during the last 10 years.

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.

Cheers

Stephen Howe