Here we will make an attempt at describing the non-Standard extensions to the library. Some of these are from SGI's STL, some of these are GNU's, and some just seemed to appear on the doorstep.
Before you leap in and use these, be aware of two things:
__mt_alloc The SGI headers
<bvector>
<hash_map>
<hash_set>
<rope>
<slist>
<tree>
are all here; <bvector> exposes the old bit_vector
class that was used before specialization of vector<bool> was
available (it's actually a typedef for the specialization now).
<hash_map> and <hash_set>
are discussed further below. <rope> is the SGI
specialization for large strings ("rope," "large
strings," get it? love those SGI folks).
<slist> is a singly-linked list, for when the
doubly-linked list<> is too much space overhead, and
<tree> exposes the red-black tree classes used in the
implementation of the standard maps and sets.
Okay, about those hashing classes... I'm going to foist most of the work off onto SGI's own site.
Each of the associative containers map, multimap, set, and multiset have a counterpart which uses a hashing function to do the arranging, instead of a strict weak ordering function. The classes take as one of their template parameters a function object that will return the hash value; by default, an instantiation of hash. You should specialize this functor for your class, or define your own, before trying to use one of the hashing classes.
The hashing classes support all the usual associative container functions, as well as some extra constructors specifying the number of buckets, etc.
Why would you want to use a hashing class instead of the "normal" implementations? Matt Austern writes:
[W]ith a well chosen hash function, hash tables generally provide much better average-case performance than binary search trees, and much worse worst-case performance. So if your implementation has hash_map, if you don't mind using nonstandard components, and if you aren't scared about the possibility of pathological cases, you'll probably get better performance from hash_map.
(Side note: for those of you wondering, "Why wasn't a hash table included in the Standard in the first #!$@ place?" I'll give a quick answer: it was proposed, but too late and in too unorganized a fashion. Some sort of hashing will undoubtedly be included in a future Standard.)
Return to top of page or to the FAQ.
Some of the classes in the Standard Library have additional publicly-available members, and some classes are themselves not in the standard. Of those, some are intended purely for the implementors, for example, additional typedefs. Those won't be described here (or anywhere else).
filebufs to be constructed from
stdio types are described in the
chapter 27 notes.Return to top of page or to the FAQ.
Currently libstdc++-v3 uses the concept checkers from the Boost library to perform optional compile-time checking of template instantiations of the standard containers. They are described in the linked-to page.
Return to top of page or to the FAQ.
Everybody's got issues. Even the C++ Standard Library.
The Library Working Group, or LWG, is the ISO subcommittee responsible for making changes to the library. They periodically publish an Issues List containing problems and possible solutions. As they reach a consensus on proposed solutions, we often incorporate the solution into libstdc++-v3.
Here are the issues which have resulted in code changes to the library. The links are to the specific defect reports from a partial copy of the Issues List. You can read the full version online at the ISO C++ Committee homepage, linked to on the GCC "Readings" page. If you spend a lot of time reading the issues, we recommend downloading the ZIP file and reading them locally.
(NB: partial copy means that not all links within the lwg-*.html pages will work. Specifically, links to defect reports that have not been accorded full DR status will probably break. Rather than trying to mirror the entire issues list on our overworked web server, we recommend you go to the LWG homepage instead.)
If a DR is not listed here, we may simply not have gotten to it yet; feel free to submit a patch. Search the include/bits and src directories for appearances of _GLIBCXX_RESOLVE_LIB_DEFECTS for examples of style. Note that we usually do not make changes to the code until an issue has reached DR status.
codecvt::do_in returns noconv there are
no changes to the values in [to, to_limit).
ios_base::failure is constructed instead.
private and are
thus inaccessible. Specifying the correct semantics of
"copying stream state" was deemed too complicated.
basic_istream
and basic_ostream all of which have been implemented.
stateT& and implement
the new effects paragraph.
max_size() rather than npos.
isspace(c,getloc()) which must be
replaced by isspace(c,is.getloc()).
getline is
not required to set gcount).
iterator and const_iterator
are constant iterators.
binder1st and binder2nd didn't have an
operator() taking a non-const parameter.
num_put::put() was overloaded on the wrong types.
num_get::get().
failbit on error now.
seekp should only set the output stream, and
seekg should only set the input stream.
op<< with a const char* was
calculating an incorrect number of characters to write.
op>> now
sets failbit (which can cause an exception, etc, etc).
set and multiset were missing
overloaded find, lower_bound, upper_bound, and equal_range functions
for const instances.
str.precision()
is specified in the conversion specification.
reverse_iterator lists a default constructor.
However, no specification is given what this constructor should do.
bad_* classes no longer have destructors (they
are trivial), since no description of them was ever given.
basic_iostream<T>::traits_type is ambiguous.
(this == &rhs) do nothing.
(this == &x) do nothing.
is.widen(0)
and is.widen(1).
codecvt<wchar_t, char, mbstate_t>::do_length
must return.
is_open.
const T&.
open clear the error flags.
data() to std::vector and
at(const key_type&) to std::map.
linear_congruential engine and seed with it.
Return to top of page or to the FAQ.
See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to the libstdc++ mailing list.