Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Standard Template Library
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Criticisms == === Quality of implementation of C++ compilers === The Quality of Implementation (QoI) of the C++ compiler has a large impact on usability of the STL (and templated code in general): * Error messages involving templates tend to be very long and difficult to decipher. This problem has been considered so severe that a number of tools have been written that simplify and [[prettyprint]] STL-related error messages to make them more comprehensible. * Careless use of templates can lead to [[code bloat]].<ref>{{Cite web|url=http://gameangst.com/?p=226|title=Minimizing Code Bloat: Template Overspecialization|author=Adrian Stone}}</ref> This has been countered with special techniques within STL implementations (e.g. using void* containers internally and other "diet template" techniques) and improving compilers' optimization techniques. However, this symptom is similar to naively manually copying a set of functions to work with a different type, in that both can be avoided with care and good technique. * Template instantiation can increase compilation time and memory usage, in exchange for typically reducing runtime decision-making (e.g. via virtual functions). Until the compiler technology improves enough, this problem can be only partially eliminated by careful coding, avoiding certain idioms, and simply not using templates where they are not appropriate or where compile-time performance is prioritized. === Other issues === * Initialization of STL [[Container (data structure)|containers]] with constants within the source code is not as easy as data structures inherited from C (addressed in [[C++11]] with [[C++11#Initializer lists|initializer lists]]). * STL containers are not intended to be used as base classes (their destructors are deliberately non-virtual); deriving from a container is a common mistake.<ref name="effcpp">{{Cite book | last = Meyers | first = Scott | title = Effective C++ Third Edition β 55 Specific Ways to Improve Your Designs | publisher = [[Addison Wesley]] | year = 2005 | isbn = 0-321-33487-6 | url = https://archive.org/details/effectivec55spec00meye }}</ref><ref name="cppcs">{{Cite book | first1 = Herb | last1 = Sutter | first2 = Andrei | last2 = Alexandrescu | author-link1 = Herb Sutter | author-link2 = Andrei Alexandrescu | year = 2004 | title = C++ Coding Standards: 101 Rules, Guidelines, and Best Practices | publisher = Addison-Wesley | isbn = 0-321-11358-6 }}</ref> * The [[Concept (generic programming)|concept]] of iterators as implemented by the STL can be difficult to understand at first: for example, if a value pointed to by the iterator is deleted, the iterator itself is then no longer valid. This is a common source of errors. Most implementations of the STL provide a debug mode that is slower, but can locate such errors if used. A similar problem exists in other languages, for example [[Java (programming language)|Java]]. [[Range (computer science)#Range as an alternative to iterator|Ranges]] have been proposed as a safer, more flexible alternative to iterators.<ref name="itersmustgo">{{cite web | author = [[Andrei Alexandrescu]] | title = Iterators Must Go | url = https://github.com/boostcon/2009_presentations/raw/master/wed/iterators-must-go.pdf | date = 6 May 2009 | access-date =19 March 2011 | publisher = BoostCon 2009 }}</ref> * Certain iteration patterns such as callback enumeration APIs cannot be made to fit the STL model without the use of [[coroutine]]s,<ref>{{Cite journal|author=Matthew Wilson |title=Callback Enumeration APIs & the Input Iterator Concept |date=February 2004 |journal=[[Dr. Dobb's Journal]] |url=http://www.ddj.com/cpp/184401766 |author-link=Matthew Wilson (author)}}</ref> which were outside the C++ standard until C++20. * Compiler compliance does not guarantee that [[Allocator (C++)|Allocator]] objects, used for memory management for [[Container (data structure)|containers]], will work with state-dependent behavior. For example, a portable library can not define an allocator type that will pull memory from different pools using different allocator objects of that type. (Meyers, p. 50) (addressed in [[C++11]]). * The set of algorithms is not complete: for example, the {{Cpp|copy_if}} algorithm was left out,<ref>{{Cite book|author=[[Bjarne Stroustrup]] |title=The C++ Programming Language |edition=3rd |isbn=0-201-70073-5 |publisher=Addison-Wesley |year=2000}}{{rp|p.530}}</ref> though it has been added in [[C++11]].<ref>[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2666.pdf More STL algorithms (revision 2)]</ref>
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Standard Template Library
(section)
Add topic