aboutsummaryrefslogtreecommitdiff
path: root/src/third_party
diff options
context:
space:
mode:
authorjimblandy@gmail.com <jimblandy@gmail.com@4c0a9323-5329-0410-9bdc-e9ce6186880e>2009-09-03 18:27:16 +0000
committerjimblandy@gmail.com <jimblandy@gmail.com@4c0a9323-5329-0410-9bdc-e9ce6186880e>2009-09-03 18:27:16 +0000
commitc426b3d98af4c3cc48d97322001963f8b886e8e9 (patch)
treee24489a8d07ac6403a88e83e8118fbe651ccfec6 /src/third_party
parentFix text field resizing for 10.5+ SDK (diff)
downloadbreakpad-c426b3d98af4c3cc48d97322001963f8b886e8e9.tar.xz
Breakpad: Don't use the deprecated __gnu_cxx::hash_map container.
Modern GNU compilers warn about the #inclusion of <ext/hash_map>; that container is deprecated, and code should use <tr1/unordered_map> instead. However, to stay within the boundaries of C++ '98, it's probably fine just to use plain old std::map. Breakpad uses hash_map in three cases: o The DWARF reader's SectionMap type maps object file section names to data. This map is consulted once per section kind per DWARF compilation unit; it is not performance-critical. o The Mac dump_syms tool uses it to map machine architectures to section maps in Universal binaries. It's hard to imagine there ever being more than two entries in such a map. o The processor's BasicSourceLineResolver uses a hash_map to map file numbers to file names. This is the map that will probably have the most entries, but it's only accessed once per frame, after we've found the frame's line entry. a=jimblandy r=nealsid git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@393 4c0a9323-5329-0410-9bdc-e9ce6186880e
Diffstat (limited to 'src/third_party')
0 files changed, 0 insertions, 0 deletions