Terms 50: Let you be familiar with the website about STL
The Internet is full of STL information. Use your favorite search engine to find "STL", it will definitely return hundreds of links, some of which may actually be relevant. However, there is no need to search for most STL programmers. The following sites should be upgraded to the top of the most common list of almost everyone:
SGI STL website, http://www.sgi.com/tech/stl/. STLPORT website, http://www.stlport.org/. Boost website, http://www.boost.org/. (Translation: If you can't access it, you can try http://boost.sourceforge.net/)
Below is a brief description of these websites worth collecting.
SGI STL website
SGI's STL website is ranked in the best, and there is a good reason. It provides a comprehensive document for each component of STL. For many programmers, regardless of which STL platform they use, this website is their online reference manual. (Reference document is prepared by Matt Austern, and then expands it and refined into "Generic Programming and the STL" [4].) The material here includes not only the STL component itself. For example, discussions about container threads in "Effective STL" (see Terms 12) are a topic based on the SGI STL website.
The SGI site provides additional things for STL programmers: a STL implementation that can be downloaded. This implementation is only ported to a small number of compilers, but the extensive transplantation of Stlport distribution is also SGI distribution, I will write more about Stlport. In addition, STL's SGI implementation provides many non-standard components that make STL programming more powerful, flexible and more interesting. These most famous are these:
Hash associated container hash_set, hash_multiset, hash_map, and hash_multimap. For more information on these containers, the steering clause 25. Single link table container, slist. As you think, it is the list node that you expect to point to. Unfortunately, this makes it expensive to implement the INSERT and ERASE members, because both require the NEXT pointer to the previous node of the iterator points to the node. In the two-way linked list (such as a standard List container), this is not a problem, but in a single-link list, a node "Back" is the operation of the linear time. This is a considerable shortcoming for SLIST, INSERT, and ERASE spending rather than constant time. SGI solves this problem by non-standard (but constant time) member functions insert_after and ERASE_AFTER. SGI is annotated,
If you find INSERT_AFTER and ERASE_AFTER, you can't meet your needs, and you often need to use Insert and Erase in the middle of the list, you may use list to replace SLIST.
Dinkumware also provides a single-link table container called SLIST, but it uses a linear time performance INSERT and ERASE implementation. For more information on Dinkumware, refer to Appendix B. A container for a similar string for a super long string. This container is called ROPE, because the rope is a heavy line (String), is it seen? SGI describes ROPE in this way:
ROPE is a scalable String: they are designed to use String as an efficient operation of a whole. For example, the time spent on assignment, series and substrings is almost independent of the length of the string. Unlike C strings, ROPE is a reasonable performance of a long string, such as editing buffer or mail information. At the rear end, ROPE is implemented as a tree of reference coupons, and each substring is stored as an array of characters. An interesting aspect of the ROPE interface is the Begin and End member functions always return const_iterator. This is to prevent customers from performing operations of changing individual characters. Such an operation is expensive, ROPE is optimized for an operation involving the entire string (as described above, for example, assignment, series and acquisition subtrial); a single character operation is very poor. Multiple non-standard functions objects and adapters. The original HP STL implementation contains more functions than it has become standard C . There are two are missing by many old STL hackers, select1st and select2nd because they are very useful for MAP and MultiMap. Given a pair, select1st returns its first component, while select2nd returns its second. These non-standard imitation functional class templates can be used:
Map
M.
...
// Write all the MAP keys to COUT
Transform (m.begin (), m.end (),
Ostream_IstRerator
(cout, "/ n"),
SELECT1ST
:: Value_type> ());
/ / Create a vector, copy all the values in the map in
Vector
V;
Transform (M.Begin (), M.End (), Back_INSERTER (V),
SELECT2ND
:: Value_type> ());
As you can see, SELECT1ST and SELECT2nd simplifies the algorithm call instead of you may have to write your own loop (see Terms 43), but if you use these imitation functions, they are non-standard facts that make you might write unavoidable and unable Maintain code (see Terms 47). The fanatic STL is not careless. They think SELECT1ST and SELECT2nd do not first enter the standard is unfair. Other non-standard functions as part of the SGI implementation include Identity, Project1st, Project2nd, Compose1, and Compose2. To know what these do, you can visit the website, although you can find the compose2 example in page 187 on this book. Now, I hope that you will clearly access the SGI website.
The SGI library achieves STL. Their goal is to develop a complete implementation of a standard C library, except for part from C (SGI thinks you already have a standard C library available). Therefore, another worthwhile download that can be obtained from SGI is the implementation of the C iostream library. As you expect, this implementation is well combined with STL's SGI, but in terms of feature performance, it is better than a lot of iostream accompanying the C compiler.
STLPORT website
The main selling point of Stlport is that it provides a modified version of the SGI STL implementation (including iostream, etc.) that can be ported to more than 20 compilers. Like SGI libraries, Stlport can be downloaded for free. If you write the code you must work in multiple platforms, you can save yourself by using its STLPORT as a standard and let all your compilers use it to give yourself a bunch of trouble.
Most Stlport's modifications to the SGI code base focused on improving transplantation, but Stlport's STL is also the only way I know that "debug mode" to help detect the incorrect usage of STL - can compile but lead to not Usage of defined running period behavior. For example, the terms 30 uses this example in writing this common error in the end of the end of the container: Int Transmogrify (int X); // This function from X
// Produce some new value
Vector
VALUES;
... // put the data into values
Vector
RESULTS;
TRANSFORM (Values.Begin (), Values.end (), // This trial
Results.end (), // exceeds Results
Transmogrify); // is written!
This can be edited, but when running, it produces undefined results. If you are lucky, terrible things will occur inside the Transform call, and debugging this problem is relatively simple. If you are not lucky, the Transform call will pour the data somewhere in your address space, but you will then find it. At that time, determine the reason for memory errors - we will say? --challenge.
Stlport's debugging mode will eliminate this challenge. When the TRANSFORM is executed above, the following message is generated (assuming that the stlport is installed in the directory C: / Stlport):
C: / Stlport / Stlport / STL / Debug Iterator.h: 265 STL Assertion Failure: _dereferenceAble (* this)
Then the program stops because the ABORT is called if the debug mode of Stlport encounters the usage error. If you like to change an exception, you can configure Stlport to your way.
It is undeniable that the above error message does not have it possible, and unfortunately, the reported files and rows correspond to the location of the internal STL assertion rather than calling the TRANSFORM line, but this is still more than crossing the Transform call, and then trying Point out why your data structure is wrong. Through Stlport's debug mode, all things you need to do is to launch your debugger, return the call stack to your code, then make sure you have done something wrong. The source code of the disgusted disgusted is generally not a problem.
Stlport's debug mode detects a variety of common errors, including the invalid range pass to the algorithm, trying to read from an empty container, using iterators from a container as the second iterator member function, etc., etc. Wait. It is tracked with each other through an iterator and its containers to complete this magic. Two iterators are given, so that they are possible to come from the same container, and when a container is modified, this makes the appropriate iterator set fail.
Because Stlport is implemented using a special iterator in debug mode, Vector and String iterators are class objects rather than the original pointer. Therefore, using Stlport and compiles the debug mode to confirm that there is a good way to distinguish between a person's sloppy processing pointer and these container type iterators. This is a reason for a chance to debug mode to Stlport debugging.
Boost website
In 1997, when the bell clocking to C international standards sounded, some people were disappointed. Part of these people is itself a member of the committee, so they began to lay the foundation for the expansion of the standard library during the second round of standardization. The result is Boost, a task is to provide a free, peer-to-counter-auction C library. The focus is on the website of the C standard library "website. Behind the task is a motive:
A library becomes "existing practice", someone increases the possibility of submitting it to future standards. Submitting a library to Boost.org is a way to build existing practices ... In other words, boost will use yourself as a good or bad authentication mechanism when a library may increase to a standard C library. This is a respectable service, and we all should be grateful.
Another reason for people who can be grateful is that you can find the library collection in Boost. I don't want to explain them here, especially because when you read these words, there is no doubt that many new libraries have been added. However, for STL users, two libraries are particularly useful. The first is a smart pointer library, including template shared_ptr for reference counting smart pointer, unlike the auto_ptr of the standard library, which can be safely stored in the STL container (see Terms 8). Boost's smart pointer also provides Shared_Array, a reference count smart pointer for dynamic allocation arrays, but Terms 13 discusses that the dynamic allocation array is not as good as Vector and String, and I hope that you have discovered that it is convincing.
Boost's second attracting STL fans are the group of the STL's function objects and related tools. The basic principles contained in these libraries are redesigned and re-implementing the idea behind the STL function objects and adapters. This result has eliminated many people constraints for standard imitation functions. As an example of such a constraint, you will find that if you try to use the BIND2ND and MEM_FUN or MEM_FUN_REF to use (see Terms 41) to block an object to a member function, and that member function gets its parameters by reference Your code is impossible to compile. If you try to use NOT1 or NOT2 and PTR_FUN and a function declare through reference parameters, you will find the same result. The reason in the case is the process of template instantiation, most STL platforms generate to reference, and the referenced reference is illegal in C . (The Standards Committee is brewing a change in the standard to solve this problem.) An example here is considered to be "a reference to the reference":
Class widget {
PUBLIC:
...
Int ReadStream (Istream & Stream); // readstream
... // Reference Acquisition Parameters
}
Vector
Vw;
...
For_each (// Most STL platforms
Vw.begin (), vw.end (), // attempt to call this call
Bind2nd (Mem_Fun (& Widget :: ReadStream) // produces one
// Reference to reference;
// that code
// Cannot compile
Boost's function object avoids this and other issues, and they are quite expanded to expand the performance of the function object.
If you are interested in the potential of STL function objects and you want to further explore it, hurry up to BOOST. If you hate the function object and think that their existence is just to comfort a few turns to C programmers, then turn to Boost. Boost's function object library is very important, but they are just a small part you can discover at that site.
