This is the
talk page for discussing improvements to the
Standard Template Library article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
Mention STL Port?
71.241.55.247 02:21, 1 December 2005 (UTC)Anon
I changed the second paragraph to emphasize modern compiler practice rather than problems resolved years ago.
71.241.55.247 02:21, 1 December 2005 (UTC)Beman Dawes (past chair of the C++ Standard Committee Library Working Group, founder of Boost)
it should be mentioned that what people today refer (imho errenously) to is *not* the HP/SGI STL and that the SGI STL contains additional stuff like slist, rope, hash_map etc. and that it never contained streams etc. and that it is confusing when people talk, since old c++ programmers really mean the sgi stl when talking about stl, and newbies mean the c++ standard library
the quote on deriving from stl containers is somehow misleading, it is not a problem, if the stl container is not treated as polymorphic class. -- 84.161.172.28 14:25, 11 July 2006 (UTC)
i agree with previous comment, there's no problem with derivation from stl containers (even if you are a novice...). 62.57.176.181 20:32, 31 December 2006 (UTC)
I absolutely do not understand what the STL concept has to do with the von Neumann computation model. And what is "value semantics" and what is its relation to the STL concept? -- 139.19.10.235 08:41, 7 September 2007 (UTC)
"This approach provides compile-time polymorphism that is often more efficient than traditional run-time polymorphism"
Says who? 72.236.149.135 15:48, 8 October 2007 (UTC) Steve
So when it says more efficient it means faster? How often is often? Has there been a performance test which we could quote? In what situations is it faster or not? ~~Steve
"value semantics". I can't believe that has its own wikipedia page. This means compare by value not by reference? Does that qualify as semantics? Useless confusing. 120.151.148.158 ( talk) 04:13, 31 January 2013 (UTC)
Why are the container adaptors (queue, priority_queue, and stack) not mentioned? They're in the specification. Herorev 06:00, 24 December 2006 (UTC)
I am struck by how nonsensical the criticism section is. I support the existence of a criticism section, but of course the criticism has to make sense first.
A standard is a standard, and every standard is revised. Just because something is not in the standard, does not make it incomplete. Bjarne admits it was his intention to include this in the standard, but that is just an interesting irreverent fact which does not affect usability. The fact of the matter is that the STL has ended the most C style pointers and pointers to pointers, or worse, pointers to pointers to pointers. I know, I used them in my old C code.
template <typename InputIterator, typename OutputIterator, typename Predicate> OutputIterator copy_if(InputIterator begin, InputIterator end, OutputIterator destBegin, Predicate p) { while (begin != end) { if (p(*begin)) *destBegin++ = *begin; ++begin; } return destBegin; }
Spoon: Roguewave also included string in their lib when they released their stl rendition. The nightmare started when stl, and string were then added to new compiler revisions, because you should not have two implementations of string, because they behave slightly differently, and make reading the code a bugger. (But this is a tangent, string is not part of the STL.).
std::string
's interface excessive, as described in his [www.stepanovpapers.com/notes.pdf Notes on Programming].
—Ben FrantzDale (
talk)
00:27, 16 May 2008 (UTC)Xerxesnine 03:16, 24 April 2007 (UTC)
The parameter binding constructs for function objects don't work with references (&), although they work with values and pointers. That once sent me debugging for days, until I discovered what it was and that it was a known issue. If I remember right, that is being adressed in the new standard, not sure though. It does work in boost, however. 217.111.33.2 ( talk) 10:16, 17 February 2011 (UTC)
decltype
(
talk)
11:42, 17 February 2011 (UTC)
It is my understanding that bitset, valarray, and string are not part of STL, but separate parts of the C++ standard library. They were adjusted to be more STL compatible. So the "Other Types of Containers" section and discussion of strings in the criticisms section should be removed.
Perhaps we need a small comment about the separation and delineation between STL and the rest of the C++ standard library, as this seems to be a source of confusion. It is alluded to in the History section ("It also influenced other parts of the C++ Standard Library, such as the string facilities...") but not explicitly stated. —Preceding unsigned comment added by 203.110.131.5 ( talk) 08:03, 8 October 2007 (UTC)
valarray
, string
, and bitset
part of the STL?valarray
was once not part of the STL, but is now part of the STL, when it says:
string
and the valarray
. The version of the STL used in this book corresponds to International Standard ISO/IEC 14882, Programming Languages -- C++, of September 1998."bitset
is now part of the STL, and the
basic_string chapter of that guide seems to imply that string
is now part of the STL. So is the current version of the STL (not the 1995 version) the same as "The parts of the current C++ Standard Library that are not included in the
C standard library"? If not, what exactly is the difference? --
68.0.124.33 (
talk)
22:43, 12 March 2009 (UTC)
I agree also. I have removed gcc and LLVM from the "Implementations section" because they implement the standard library. The reference for the gcc bullet point makes no mention of STL. Wqwt ( talk) 01:54, 14 March 2020 (UTC)
Probably the most useful and most used part of STL is the vector container. I think it is a significant criticism that vector has speed inefficiencies when compared to use of C arrays and memmove. There has been quite a bit of discussion of this in various forums which has generated more heat than light. This would be the ideal place to clarify this.
Note that this criticism is often dismissed as poor use of vector. Indeed in many cases judicious use of vector::reserve() would resolve it. However, there are still many situations where vector is less than ideal. For example, it is the reason that vector itself is never used in the implementation of deque.
BTW I agree with the above discussion under "Strange Criticism section". —Preceding unsigned comment added by 203.110.131.5 ( talk) 08:31, 8 October 2007 (UTC)
lol.....Ok, C++ is slower then C. And C is slower then assembler. Perhaps you should program in assembler if you consider this a flaw. lol. C and C++ are the fastest executables compiled today. STL does not change that fact. I've never worked somewhere where they decided that the code needed to run 20% faster, it's always been multiple times faster that they want. The diffrence between C++ and C is quite honestly, a percentage difference. The difference between C and C++ compiled code, is not something the employer has ever worried about (except for Shannon Labs at AT&T, and Credit Suisse Asset Management, etc.). As long as we are on this tangent, then fyi, fopen and open do not invoke locale like the c++ stream file opens. Now, there is an important thing to know about C vs C++, and how to program for the fastest hard drives of today. But, that means nothing for anyone programming for a PC, since no customer is going to have a rack mounted shark hard drive on their laptop. 95% (i'm guessing) of all C++ programming still can use ifstream, and ofstream, and enjoy the benefits of streams, and not fret about being up to 20% slower then using straight C. — Preceding unsigned comment added by 162.72.225.8 ( talk) 14:14, 16 July 2013 (UTC)
I think the speed and efficiency gripes are mostly imaginary. Much of it depends on style anyway. There are numerous demonstrable cases where C++ produces better machine code than C simply because the optimizer can reason better about C++ than it can about C. It is true that this used to be a problem in the 1990s, but if you are using old compiler technology and old programming practices in C++, then you are asking for bad performance. 2003:69:CD04:2601:2E81:58FF:FEFF:8F4B ( talk) 12:56, 15 September 2013 (UTC)
Thanks, -- Abdull ( talk) 13:54, 23 January 2010 (UTC)
Article claims that first implementations werent thread safe, but AFAIK current ones aren also. Only thread safety guarantee is that multiple readers can read without problems, but multiple writes are undefined behavior. — Preceding unsigned comment added by 92.251.82.38 ( talk) 13:44, 2 August 2011 (UTC)
It is up to the programmer to write thread safe code. This is why we have mutexes and "critical sections". Generally, speaking, most multithreaded code is unnecessary and could have been done with multiprocesses each running in a single thread. — Preceding unsigned comment added by 162.72.225.8 ( talk) 15:09, 16 July 2013 (UTC)
There's an ongoing discussion about whether Standard Template Library is a proper noun or not. Please express your opinion. 1exec1 ( talk) 17:40, 3 December 2011 (UTC)
Is this about the elements of the C++ standard library that were originally inspired by and modeled after parts of STL, or is it about STL and its legacy? It seems like that page can't decide: it opens talking about STL in present tense, but describes the long-abandoned library, then it lists some of the C++ containers, many of which were once modeled after the interfaces defined in STL, then it vaguely mentions iterators, algorithms, and functors (vague enough to fit either focus), and then talks about the history of the actual STL until the first C++ standard. Then there's the low-quality 'criticisms' section, and then there's a list that mixes STL implementations with C++ libraries, some of which aren't STL implementations (missing things like rope, compose2, select1st, 3-way compare, random_sample, bit_vector, Monoid, not to mention all the changes and extensions of the STL-based content in the C++ library that occurred in the last 15 years). -- Cubbi ( talk) 17:28, 24 September 2013 (UTC)
The History section states that real programming languages didn't support generic programming before 1979. ML supported it several years before then, as noted in the Generic programming article. Don Biggles ( talk) 02:14, 28 April 2016 (UTC)
EASTL is not a proper STL implementation, [1]. Marcofoco ( talk) 17:12, 12 May 2016 (UTC)
Some people use STL as just a short form of "STandard Library"... And there are some other misconceptions... See pop http://stackoverflow.com/a/5205571/287948 -- Krauss ( talk) 01:58, 4 November 2016 (UTC)
Bogra is now called Bogura. — Preceding unsigned comment added by 103.77.19.163 ( talk) 16:59, 24 July 2019 (UTC)
I am amazed that Boost is not explicitly credited with improving the STL. This is, at a minimum, unfair and in my opinion actually dishonest...or at least unethical. 40.142.185.108 ( talk) 16:05, 25 July 2019 (UTC)
This is the
talk page for discussing improvements to the
Standard Template Library article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
Mention STL Port?
71.241.55.247 02:21, 1 December 2005 (UTC)Anon
I changed the second paragraph to emphasize modern compiler practice rather than problems resolved years ago.
71.241.55.247 02:21, 1 December 2005 (UTC)Beman Dawes (past chair of the C++ Standard Committee Library Working Group, founder of Boost)
it should be mentioned that what people today refer (imho errenously) to is *not* the HP/SGI STL and that the SGI STL contains additional stuff like slist, rope, hash_map etc. and that it never contained streams etc. and that it is confusing when people talk, since old c++ programmers really mean the sgi stl when talking about stl, and newbies mean the c++ standard library
the quote on deriving from stl containers is somehow misleading, it is not a problem, if the stl container is not treated as polymorphic class. -- 84.161.172.28 14:25, 11 July 2006 (UTC)
i agree with previous comment, there's no problem with derivation from stl containers (even if you are a novice...). 62.57.176.181 20:32, 31 December 2006 (UTC)
I absolutely do not understand what the STL concept has to do with the von Neumann computation model. And what is "value semantics" and what is its relation to the STL concept? -- 139.19.10.235 08:41, 7 September 2007 (UTC)
"This approach provides compile-time polymorphism that is often more efficient than traditional run-time polymorphism"
Says who? 72.236.149.135 15:48, 8 October 2007 (UTC) Steve
So when it says more efficient it means faster? How often is often? Has there been a performance test which we could quote? In what situations is it faster or not? ~~Steve
"value semantics". I can't believe that has its own wikipedia page. This means compare by value not by reference? Does that qualify as semantics? Useless confusing. 120.151.148.158 ( talk) 04:13, 31 January 2013 (UTC)
Why are the container adaptors (queue, priority_queue, and stack) not mentioned? They're in the specification. Herorev 06:00, 24 December 2006 (UTC)
I am struck by how nonsensical the criticism section is. I support the existence of a criticism section, but of course the criticism has to make sense first.
A standard is a standard, and every standard is revised. Just because something is not in the standard, does not make it incomplete. Bjarne admits it was his intention to include this in the standard, but that is just an interesting irreverent fact which does not affect usability. The fact of the matter is that the STL has ended the most C style pointers and pointers to pointers, or worse, pointers to pointers to pointers. I know, I used them in my old C code.
template <typename InputIterator, typename OutputIterator, typename Predicate> OutputIterator copy_if(InputIterator begin, InputIterator end, OutputIterator destBegin, Predicate p) { while (begin != end) { if (p(*begin)) *destBegin++ = *begin; ++begin; } return destBegin; }
Spoon: Roguewave also included string in their lib when they released their stl rendition. The nightmare started when stl, and string were then added to new compiler revisions, because you should not have two implementations of string, because they behave slightly differently, and make reading the code a bugger. (But this is a tangent, string is not part of the STL.).
std::string
's interface excessive, as described in his [www.stepanovpapers.com/notes.pdf Notes on Programming].
—Ben FrantzDale (
talk)
00:27, 16 May 2008 (UTC)Xerxesnine 03:16, 24 April 2007 (UTC)
The parameter binding constructs for function objects don't work with references (&), although they work with values and pointers. That once sent me debugging for days, until I discovered what it was and that it was a known issue. If I remember right, that is being adressed in the new standard, not sure though. It does work in boost, however. 217.111.33.2 ( talk) 10:16, 17 February 2011 (UTC)
decltype
(
talk)
11:42, 17 February 2011 (UTC)
It is my understanding that bitset, valarray, and string are not part of STL, but separate parts of the C++ standard library. They were adjusted to be more STL compatible. So the "Other Types of Containers" section and discussion of strings in the criticisms section should be removed.
Perhaps we need a small comment about the separation and delineation between STL and the rest of the C++ standard library, as this seems to be a source of confusion. It is alluded to in the History section ("It also influenced other parts of the C++ Standard Library, such as the string facilities...") but not explicitly stated. —Preceding unsigned comment added by 203.110.131.5 ( talk) 08:03, 8 October 2007 (UTC)
valarray
, string
, and bitset
part of the STL?valarray
was once not part of the STL, but is now part of the STL, when it says:
string
and the valarray
. The version of the STL used in this book corresponds to International Standard ISO/IEC 14882, Programming Languages -- C++, of September 1998."bitset
is now part of the STL, and the
basic_string chapter of that guide seems to imply that string
is now part of the STL. So is the current version of the STL (not the 1995 version) the same as "The parts of the current C++ Standard Library that are not included in the
C standard library"? If not, what exactly is the difference? --
68.0.124.33 (
talk)
22:43, 12 March 2009 (UTC)
I agree also. I have removed gcc and LLVM from the "Implementations section" because they implement the standard library. The reference for the gcc bullet point makes no mention of STL. Wqwt ( talk) 01:54, 14 March 2020 (UTC)
Probably the most useful and most used part of STL is the vector container. I think it is a significant criticism that vector has speed inefficiencies when compared to use of C arrays and memmove. There has been quite a bit of discussion of this in various forums which has generated more heat than light. This would be the ideal place to clarify this.
Note that this criticism is often dismissed as poor use of vector. Indeed in many cases judicious use of vector::reserve() would resolve it. However, there are still many situations where vector is less than ideal. For example, it is the reason that vector itself is never used in the implementation of deque.
BTW I agree with the above discussion under "Strange Criticism section". —Preceding unsigned comment added by 203.110.131.5 ( talk) 08:31, 8 October 2007 (UTC)
lol.....Ok, C++ is slower then C. And C is slower then assembler. Perhaps you should program in assembler if you consider this a flaw. lol. C and C++ are the fastest executables compiled today. STL does not change that fact. I've never worked somewhere where they decided that the code needed to run 20% faster, it's always been multiple times faster that they want. The diffrence between C++ and C is quite honestly, a percentage difference. The difference between C and C++ compiled code, is not something the employer has ever worried about (except for Shannon Labs at AT&T, and Credit Suisse Asset Management, etc.). As long as we are on this tangent, then fyi, fopen and open do not invoke locale like the c++ stream file opens. Now, there is an important thing to know about C vs C++, and how to program for the fastest hard drives of today. But, that means nothing for anyone programming for a PC, since no customer is going to have a rack mounted shark hard drive on their laptop. 95% (i'm guessing) of all C++ programming still can use ifstream, and ofstream, and enjoy the benefits of streams, and not fret about being up to 20% slower then using straight C. — Preceding unsigned comment added by 162.72.225.8 ( talk) 14:14, 16 July 2013 (UTC)
I think the speed and efficiency gripes are mostly imaginary. Much of it depends on style anyway. There are numerous demonstrable cases where C++ produces better machine code than C simply because the optimizer can reason better about C++ than it can about C. It is true that this used to be a problem in the 1990s, but if you are using old compiler technology and old programming practices in C++, then you are asking for bad performance. 2003:69:CD04:2601:2E81:58FF:FEFF:8F4B ( talk) 12:56, 15 September 2013 (UTC)
Thanks, -- Abdull ( talk) 13:54, 23 January 2010 (UTC)
Article claims that first implementations werent thread safe, but AFAIK current ones aren also. Only thread safety guarantee is that multiple readers can read without problems, but multiple writes are undefined behavior. — Preceding unsigned comment added by 92.251.82.38 ( talk) 13:44, 2 August 2011 (UTC)
It is up to the programmer to write thread safe code. This is why we have mutexes and "critical sections". Generally, speaking, most multithreaded code is unnecessary and could have been done with multiprocesses each running in a single thread. — Preceding unsigned comment added by 162.72.225.8 ( talk) 15:09, 16 July 2013 (UTC)
There's an ongoing discussion about whether Standard Template Library is a proper noun or not. Please express your opinion. 1exec1 ( talk) 17:40, 3 December 2011 (UTC)
Is this about the elements of the C++ standard library that were originally inspired by and modeled after parts of STL, or is it about STL and its legacy? It seems like that page can't decide: it opens talking about STL in present tense, but describes the long-abandoned library, then it lists some of the C++ containers, many of which were once modeled after the interfaces defined in STL, then it vaguely mentions iterators, algorithms, and functors (vague enough to fit either focus), and then talks about the history of the actual STL until the first C++ standard. Then there's the low-quality 'criticisms' section, and then there's a list that mixes STL implementations with C++ libraries, some of which aren't STL implementations (missing things like rope, compose2, select1st, 3-way compare, random_sample, bit_vector, Monoid, not to mention all the changes and extensions of the STL-based content in the C++ library that occurred in the last 15 years). -- Cubbi ( talk) 17:28, 24 September 2013 (UTC)
The History section states that real programming languages didn't support generic programming before 1979. ML supported it several years before then, as noted in the Generic programming article. Don Biggles ( talk) 02:14, 28 April 2016 (UTC)
EASTL is not a proper STL implementation, [1]. Marcofoco ( talk) 17:12, 12 May 2016 (UTC)
Some people use STL as just a short form of "STandard Library"... And there are some other misconceptions... See pop http://stackoverflow.com/a/5205571/287948 -- Krauss ( talk) 01:58, 4 November 2016 (UTC)
Bogra is now called Bogura. — Preceding unsigned comment added by 103.77.19.163 ( talk) 16:59, 24 July 2019 (UTC)
I am amazed that Boost is not explicitly credited with improving the STL. This is, at a minimum, unfair and in my opinion actually dishonest...or at least unethical. 40.142.185.108 ( talk) 16:05, 25 July 2019 (UTC)